The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: PC Tweakage

Remembering which tweaks worked

  • Kmail: FAIL

    In the unlikely event you’re keeping track of this, slashing the total volume of email made Kmail much more competent: it hadn’t trashed an index file in, oh, weeks…

    Until it happened again.

    I don’t know that 30 days of email is magic, but 64 MB worked much better than 3 GB. The offending folder has all of 6 MB and 280 files, which puts a pathetic upper bound on Kmail’s good behavior.

    Anyhow, Kmail still screws up its indexes, but … it’s better than it was.

    You’d think this would be an important thing to get right, but the KDE apparat has far more important things to worry about. Eye candy, as nearly as I can tell.

    I use Kmail because it’s one of the few email readers that stores messages in maildir format. That’s important with large email collections, because mbox, the other choice, tucks all the messages into a single honkin’ big file (perhaps one file per folder). That doesn’t work well with a daily backup strategy, because each message changes the file and triggers a backup of the whole thing. Maildir format means backing up only the new messages, which makes far more sense.

    But, if this blank email thing continues, it’s time to move on…

  • Kmail: Copying Directory Structures and Some Files Therein

    As part of the Kmail blank email problem, I conjured up a new, shrunken maildir structure with just the most recent 30 days of email. However, I want to keep all the same folders, even if they have no current email messages, so my filters can sort the incoming mail properly.

    The sequence of events:

    • shut down Kmail!
    • move existing email directory out of the way
    • set up a new directory
    • copy the directory structure
    • copy the most recent 30 days of email
    • delete the existing index files

    That’s straightforward, at least after you figure it out. Took me a while to get it right, but here ya go…

    cd to the directory holding the Mail folder
mv Mail Mail.base
mkdir Mail
cd Mail.base
find . -type d -print0 | cpio --null -dmpv ../Mail
find . -type f -mtime -30 -print0 | cpio --null -apdv ../Mail
cd ../Mail
find . -type f -name ".*index" -print0 | xargs -0 rm
find . -type f -name ".*index.ids" -print0 | xargs -0 rm

    Then fire up Kmail and let it rebuild all the index files.

    You ought to try that out on a dummy version of your email, as something may have gotten clobbered in the transition from my terminal to your fingertips, OK?

  • KMail: The Blank Email Problem

    Of late, Kmail has been turning email messages into complete blanks: the Subject, From, Date, and body are all completely blank. This is evidently a problem of long standing with Kmail and has something to do with fumbling the indexes that point to the emails within its maildir directory structure.

    The FAQ blandly notes:

    You have empty ‘ghost-mails’ in your inbox (or other folder)

    Symptom: For some reason, certain messages aren’t accessible in KMail. They show up in the message list window but selecting them there results in a blank message window. I can’t open them or reply to them, etc.

    Solution: This problem ist most likely due to corrupted index files, see issue ‘You are loosing mail’ above. So just follow the advice given there.

    Well, yeah, except that rebuilding the indexes more than once a day seems excessive… and the problem is, intermittently, much worse than that.

    I’m running KMail in XFCE, which introduces some complexity, but other folks with the same problem are running it in bone-stock KDE. Surprisingly the recent 4.x upheavals haven’t changed the problem in the least.

    I’ve been keeping the maildir structure on the file server, rather than my local drive, and symlinking to it from my home directory through NFS. That also doesn’t seem to change the symptoms, although putting a heavy load on either the network or the server sometimes increases the number of blank emails.

    Over the last few months I’ve tried a number of things, like tweaking NFS buffer sizes & timings, to no avail. Time to start writing this stuff down…

    With that as prologue, here’s how to recover those blank emails.

    Most important: when you see a blank email, get out of Kmail. Nothing you do within Kmail will help and many things will hurt, so just bail out.

    Fire up a terminal window and cd to the directory representing that email folder. First-level folders have the obvious name, but all the second-level folders are in hidden directories. For example, I have a top-level folder called Bulk Stuff, with one sub-folder (among many) being EMC.

    The directory structure:

    Mail/Bulk Stuff/
Mail/.Bulk Stuff.directory/EMC/

    Yeah, embedded blanks. Sue me.

    Each of those directories has three subdirectories: cur, new, and tmp.

    The problem seems to arise when a new message gets transferred from new to cur, although sometimes existing messages in cur go bad. The index entry seems to point to the wrong place; the actual mail message file is in cur, but the index points off into the bushes somewhere.

    The solution is to manually move the file from cur back to new, then rebuild the offending index. Leaving it in cur and just rebuilding the index does not always work, for reasons I do not understand.

    The easiest way to find the newest messages:

    cd "Mail/.Bulk Stuff.directory/EMC"
ll cur | tail

    This will show the most recent few entries, which will look something like this:

    -rw-r--r-- 1 ed ed 22256 2010-04-19 20:48 1271724492.2194.DbdZD:2,S
-rw-r--r-- 1 ed ed 23513 2010-04-20 13:09 1271783386.2232.jxmG6:2,S
-rw-r--r-- 1 ed ed 20901 2010-04-20 17:10 1271797805.2232.i6fP3

    The last line shows the most recent files hasn’t been read yet, which is a tipoff that something’s wrong. If you have an older message with a rotten index entry, use grep (or some such) to find it.

    Move the file back to new and delete the corresponding index files:

    mv cur/1271797805.2232.i6fP3 new
cd ..
rm ".Bulk Stuff.index*"

    Then fire up Kmail again and it’ll automagically rebuild the indexes. That’ll work fine for a while, then it’ll screw up again.

    I suspect that the problem is related to either the number of messages or the index file size for each maildir directory. I have, in round numbers, 3 GB of mail stashed away. As with anything, most of it is useless , but I occasionally need one of those messages ever so urgently.

    I set up a new maildir structure with only the last 30 days of email transactions, which should be enough to either eliminate the problem or show that Too Many Messages is just another dead end.

    More details on that tomorrow…

  • Running the AADE Filter Design Program in WINE

    This requires a bit of hocus-pocus, all of which you can find by diligent searching. Nothing original here, but I’m sure to need it again one of these days.

    To install THREED32.OCX:

    winetricks mfc40

    To fix the “ActiveX component can’t create object” error, you can try the process described there. It didn’t work for me, but one of the messages points out that the error is tied to the nag screen, which will vanish after 10 (?) iterations. That worked, although I admit to losing track of the number of crashes.

    Alas, the Help function crashes with that same message while trying to invoke the HELP menu item; the crash brings down the entire program. So it goes.

    Anyhow, in the process of figuring that out, I fetched the msscript.ocx file from the Windows installation on this box:

    sudo mount -o ro,uid=ed /dev/sda2 /mnt/part
find /mnt/part/WINDOWS/ -iname "msscript*"

    Which reports it’s located at:

    /mnt/part/WINDOWS/system32/msscript.ocx

    Copy it locally for convenience:

    cp /mnt/part/WINDOWS/system32/msscript.ocx ~/.wine/drive_c/users/ed/My\ Documents
sudo umount /mnt/part

    Then you can register the control:

    regsvr32 ~/.wine/drive_c/users/ed/My\ Documents/msscript.ocx

    The program entry shows up in the “Other” category of the XFCE menu structure. I added a launcher and eventually found the icon:

    ~/.local/share/icons/32ce_filter.0.xpm

  • Ancient CM11A X10 Controller Pinout

    I have an X10 CM11A “Two Way Computer Interface” handling the very very very few scheduled events for our house. Basically, it turns the living room lights on in the evening and everything off much later.

    As a result, I tend to ignore it for years at a time. A recent power outage killed the regularly scheduled events, which suggested that the backup batteries needed changing… and, yes, they were pretty well corroded.

    With that out of the way, I discovered that the last time I’d loaded a program into the thing was so long ago that the heyu config files had either gone missing or were on a system not near the top of my heap. It’s easy enough to configure, so I installed heyu and spun up a new set of config files.

    All the doc I can find says the CM11A has an RJ11 modular phone jack, which mates with the standard 6-position 4-conductor dingus found on the end of every phone in this part of the world. My CM11A, however, has a 4P4C jack, the narrower dingus found on phone handsets. Given that heyu reports

    Firmware revision Level = 1

    I suspect that this thing is slightly older than some of the folks reading this post and the X10 factory switched to a somewhat less bizarre connector in mid-stream.

    Anyhow, the DB9 (yeah, it’s a DE9, but nobody calls it that) connector has “X10 Active Home” printed on it in my very own handwriting, with a standard RJ11 plug on the end. A double-jack adapter connects a hank of cable with an RJ11 plug on one end and a 4P4C connector on the other. I have no idea where that cable came from; perhaps I replaced the 4P4C plug with something less bizarre to add that extension so the cable would stretch from PC to wall outlet?

    I plugged the thing into a USB-RS232 adapter and heyu had no trouble talking to the CM11A. However, trying to execute

    heyu dim n13 10

    produced the discouraging report

    RI serial line may be stuck.

    A bit of deft multimeter work produced this pinout list, which agrees with most of the doc you’ll find elsewhere. Hold the 4P4C connector with the tab down and the cable away from you: the pin numbers are 4 3 2 1 from left to right. The RS-232 pins are printed right on the DB-9 connector.

    4P4C   DB9
 1      2 RxD
 2      9 RI
 3      3 TxD
 4      5 Gnd

    It’s entirely possible the USB converter doesn’t support RI or it doesn’t do a good job of it. I jammed the cable into the serial port on the back of the PC and shazam it works perfectly.

    The x10.conf file, for the next time around

    TTY /dev/ttyS0

HOUSECODE N

LATITUDE 	41:40N
LONGITUDE	73:53W

ALIAS MBR_Dresser	N1
ALIAS Front_Hall	N5
ALIAS RV_XCVR		N9
ALIAS Couch		N10
ALIAS Mary_Reading	N11
ALIAS LR_Ceiling	N12
ALIAS Fireplace		N13
ALIAS Kitchen		N14
ALIAS Patio		N15
ALIAS Garage_Spots	N16

START_ENGINE	AUTO

LOG_DIR		/var/log/heyu/

DATE_FORMAT	YMD '-'

  • Dell Inspiron 8100: VGA Kernel Options

    Just installed CrunchBang Linux on the old Dell Inspiron 8100 (1 GHz 512 MB Pentium III laptop) to get some experience with OpenBox and maybe make the thing usable with the Arduino IDE on my electronics workbench.

    As with most distros, it features a totally useless boot progress thermometer splash screen that hides all the interesting details. Carving the splash quiet options off the kernel line in /boot/grub/menu.lst gets back to the usual torrent of text info, which I find comforting. But the default screen is 80×25, which means things scroll by at a pretty good clip…

    Adding vga=ask to the kernel line lets you dump what the BIOS thinks will work. This includes:

    • 0x345 or 0x346 = 1600x1200x16
    • 0x315 = 800x600x32
    • 0x31A = 1280x1024x16

    Plus a whole bunch of other modes that don’t matter much these days. Anyone for 40×25 text mode?

    I wanted 1600×1200, but both of the listed options caused a garbled display: double-spaced raster lines and eventual overlapping wrapped text. There’s probably a BIOS bug in there somewhere.

    Choosing the 80×60 modes produced truly ugly squashed text.

    After some poking around, 0x31A produced a usable display that, to my wondering eyes, appears to be 1600×1200. The kernel expects the decimal equivalent of that value: vga=794.

    It’s plenty dense enough for all the boot text…

  • Why Friends Don’t Let Friends Run Windows: Mystery Banking DLL

    So I signed into the credit union’s online banking site, did the multi-factor authentication dance, and was confronted with this dialog box…

    HVFCU Mystery DLL Download
    HVFCU Mystery DLL Download

    No, as a matter of fact, I did not choose to open ibank.dll, thank you very much for asking.

    Well, what would you do?

    Got this response from the credit union’s email help desk:

    Upon speaking to out Information Technology department, I have been advised that this is a known problem for FireFox, Mac, and Linux users.

    Hmmm, well now, Internet Explorer is conspicuous by its absence on that list, isn’t it?

    A bit more prodding produced this response:

    HVFCU uses a third party vendor to provide the Internet Banking software used on our servers.  On November 22 we installed the equivalent of their year end release (which is mandatory due to regulatory changes contained in the release).  Subsequent to that upgrade we discovered that errors had been introduced for Mac and/or Linux users of Safari and FireFox (and also for a small subset of Windows Internet Explorer users).  These same errors do not occur on Safari nor FireFox running on Windows.  We reported these problems to our vendor within 24 hours of the installation.

    My guess is that the “small subset of Windows Internet Explorer users” corresponds to the few who actually armored-up their IE security settings enough that it doesn’t automatically download and execute anything offered to it from any website.

    The rest, well, those PCs are most likely part of a zombie botnet.

    He assured me:

    The “ibank.dll” program cannot run on a Mac nor a PC.  It is solely a server side application which generates HTML pages.

    Just guessing here, but if the “misconfiguration” had extended to actually serving the file, well, it probably would have run just fine (or, at least, attempted to run) on any Windows PC. They are, after all, using DLLs on the server, so it’s not like they’re a Unix-based shop.

    And it’s pretty obvious that their vendor’s testing extended only far enough to verify that the code worked with security settings dialed to “Root me!” Maybe they didn’t actually do any testing at all; this was, after all, just an end-of-year update. What could possibly go wrong?

    If you’re wondering why your Windows-based PC has been behaving oddly, maybe you’ve gotten a drive-by download from a trustworthy site with all the appropriate icons on their home page.

    Makes you really trust the banking system, doesn’t it?

    Or maybe it’s just another reason to stop using Windows…