[browse$]
        path =/dev/null
        comment = browseable share to make leopard happy
        write list = nobody
        writeable = no
        browseable = yes
        guest ok = no
        create mask = 644
        directory mask = 755
        force group = nobody
        force user = nobody

tell application "Eudora"
     compact
end tell

current mood: accomplished

1. Converting Eudora files
   Eudora technical support have a document called Migrating from MAC to Windows that outlines the migration procedure. One of the big problems is dealing with the differences in the eond-of-line characters used by each operating system. The document suggests FTPing the files in text mode so that this conversion process happens automagically for you. But what do you do if your computing environment doesn't allow you to FTP between Mac and Windows?
   
   Fortunately the user only had a few (~5) mailboxes; these were transferred to Windows, opened in Microsoft Word (which fortunately understands Mac, Windows and UNIX EOL markers) and save as out as Windows text files.



2. Lack of file extensions
   MacOS 9 doesn't use file extensions - it uses the MacOS creator code and file type to identify what type of file it is dealing with. I wrote an some applescript code to rename common file types with the appropriate extension
   
   ( The Applescript code )
   
   If you're going to use this code, obviously you'll need to change the file location specified in the line
   
   set outputFile to "HD2:rename_problems.txt"
   
   to point to somewhere on your own system.
   
   Unfortunately, while the code works brilliantly on a MacOS X machine, it has a tendency to fall over under MacOS 9 with a somewhat cryptic error message:
   
   because *Ox//* the original item cannot be found
   
   Fortunately I have a MacOS X machine handy, so I transferred the user's files to it and ran the script over the files.
   
   The user had Office documents created by four different generations of Office for Mac, but fortunately the creator code for the files hadn't changed in that time. The script's treatment of Office documents is a bit rough-and-ready - basically anything created by Word gets ".doc" as it's extension, regardless of whether it is a Word doc, an RTF doc, a document template or whatever. Same goes for Excel docs (they all get ".xls") and PowerPoint docs (they all get ".ppt"). Office 2003 seems perfectly capable of figuring out what the files are at the receiving end.
   
   The output file produced by the applescript code lists files the script couldn't deal with - some are locked, and some just generate problems which are (apparently) due to the phase of the moon. More interestingly, after going in and manually correcting the problems it identified on the first run, it found a number of additional problems on the second run. It took four runs in all before it ran without complaint. This was still much faster than renaming every single file by hand.


3. Illegal file names
   The last problem was with illegal filenames - the user had used a lot of characters in their filenames that are illegal as far as Windows filenames are concerned. Since the files were now on the MacOS X machine, I was able to write a short Perl script to remove all of those illegal characters from the file names.
   
   ( The perl script )
   
   It's interesting to note that this Perl script took less than five seconds to run over the entire directory structure containing the user's files - the Compiled Applescript application took ~5 minutes. If I need to use this again, I'll probably rewrite the applescript code in Perl so that the one script does the whole lot.
   

1. Open a Word document.


2. Choose "Styles and Formatting..." from the "Format" menu


3. The Styles menu will appear on the right-hand side of the Word window. Right-click on the "Normal Style", and choose "Modify" from the content menu.


4. The "Modify Style" dialog box will appear. Uncheck the "Automatically update" box.


5. Click on the "OK" button.

current mood: working