Conversion from MacOS to Dual-boot (Windows/Linux)
Mark Foster
NREN / Recom Technologies
October 1999

In the process of switching from a Mac to a Windows/Linux platform as my primary desktop machine, I found a handful of instructions and associated utilities helpful. I also found that some of the conversion process was tedious and/or error-prone, so wrote a few simple scripts to help. This note gives some of the details of my experience, in hopes that others might benefit from it.

At the outset, I faced two major types of problems (well, the user interface between MacOS 8.1 and Windows 98 is quite different, but I’m talking about more structural differences at this point). The first problem was how to transfer the several hundred MBs of data from the Mac drive to the PC drive. The second was how to cope with different file representations for some applications. In my case, the solutions to both these problems were at least partially solved with Linux (RedHat 6.0) functionality.

The file transfer problem could have been handled by using external media such as multiple Zip cartridges; the PC came with a Zip drive installed, and I could have borrowed an external Zip drive to install on the Mac. The added benefit with this approach would have been that I had a "clean" external snapshot of the data being transferred. Since both machines were plugged into the same ethernet, I decided it might be equally easy to use a network-based transfer.

One approach to network-based transfer would have been to use ftp to copy individual files between the machines; using something like ‘fetch’ on the Mac, and running an ftp server on the PC would have accommodated this approach. However, because I had quite a large number of files, in a fairly structured hierarchy, it would have been painful and slow to move files and directories piecemeal.

Another approach was to setup fileservice, where one machine acts as a client of the other; with Linux, this is readily accomplished by enabling the Appleshare Filing Protocol Daemon (afpd). This daemon allows the PC to act as an AppleShare volume, and to be mounted (readable and writable) as a network disk on the Mac. By dragging and dropping Mac folders, the copying (including all the hierarchy) is readily accomplished. This method leaves behind .AppleDouble subdirectories that are where the resource branch of the MacOS files get stored. The .AppleDouble directories can safely be deleted after the copying process is completed. Another caveat: if a file or directory has a "/" in it’s name, it won’t get properly copied; I’d suggest searching for and renaming any such files before the copy process is started.

When setting up afpd, I made the decision to allow the default export (user’s home directory is the mounted directory), so when the files were copied, they were placed in a subdirectory of my Linux user home directory. Once the files were on the Linux disk, I could then take steps needed to deal with the second main problem: the file representations.

I should note that the ultimate goal was to have my files accessible both to the Windows environment and to the Linux environment. This setup can be accomplished by making the Windows partition available to Linux using the vatfs filesystem mount type (vatfs observes and handles the long filenames used by Windows 98), then storing the files on the Windows partition. So something like the following:

# mount –t vatfs /dev/hda1 /win

will make the first partition available under the "/win" directory. Some of the steps I outline below were used prior to copying files to /win, some afterward. I don’t think a distinction is important, although if you’re doing something similar, you will want to be sure to keep track of where the "current" files are, and discard or archive the inactive copies.

For the most part, I use a fairly limited set of applications, so the types of files are pretty limited: MS Word, Excel, and PowerPoint are key, as are Eudora for email, and Netscape bookmarks. Following the copy from MacOS to Windows, nearly all of these files were immediately readable by the corresponding application (I did have to copy the bookmarks into the Netscape directory). The lone exception was the Eudora mail folders. These folders, in fact, required quite a bit of work (I was using Eudora Pro 4.2 on both systems).

I found some pretty helpful (although slightly dated) information on the Eudora web site. An overview of the steps described is:

1. Rename the folders and mailbox files:

A mailbox file "In" becomes "IN.MBX"
A mail folder (directory) "Misc" becomes "Misc.FOL"

2. Convert each MBX file so the end-of-line terminator is <CR><LF> (Macs and Unix machines use just <LF>)
3. Convert Filters file, copy to FILTERS.PCE
4. Convert Nicknames and Address folders

Since I didn’t have any Filters or Nicknames, I was able to skip steps 3 and 4. For additional detail on each of these steps, see http://www.eudora.com/techsupport/kb/1333hq.html.

One major item missing from these steps is how to deal with attachments. Doing per-message patching for the attachments is best done programmatically. Likewise, the renaming process, and CRLF conversion are tedious and subject to typing mistakes if done manually. Below I’ve included copies of the quick hacks I did to accomplish these tasks. Here is how I used them:

I used eudorambx to convert the directory names and mailbox names to use .fol and .mbx suffixes, respectively. A little manual work was needed for files that had "space" in their names… with just a little more work on the script, it could handle this too, but I had very few of these, so decided the manual process was fine.

I used addcr to insert a <CR> before the <LF> in each file.

I copied the MacOS Eudora attachment files from the "System Folder/Eudora Folder/Attachments Folder" directory to the "C:\Program Files\Qualcomm\Eudora Mail\Attach" directory (note that when doing this copy under Linux, the equivalent directory can be used:

"/win/Program Files/Qualcomm/Eudora Mail/Attach"). With the attachments in the proper location, what remained to be done was change the pathname stored within each associated message. The pathname to the attachments file in each message must be the Windows pathname, not the Linux pathname. This procedure was done using the script reattach.

#!/bin/csh -f
# eudorambx - change filenames for eudora windows:
# change names of directories to have .fol suffix
# change names of plain files to have .mbx suffix
#
# usage: eudorambx file1 file2 ...
#
# care is taken since some files might contain space in their name


set cmd = $0

set flist = ($*)
foreach f ($flist)

    if (-f "$f") then
	set nf = "$f"
           if ("$nf" !~ *.mbx) then
	      	set nf = "$f".mbx
    		mv "$f" "$nf"
	   endif
           addcr < "$nf" > "$nf".tmp ; mv "$nf".tmp "$nf"
    else if (-d "$f") then
	set d = "$f"
	if ("$d" !~ *.fol) then
	    set d = "$f".fol
	    mv "$f" "$d"
	endif
	# recurse 
	echo "traversing $d"
	$cmd "$d"/*
    endif
end

#!/usr/bin/perl
# insert <cr> to create <cr><lf> at end of line (for DOS/WIN apps)
# safe to run multiple times over the same file, since it checks for
# existing <cr><lf>, and does nothing if it's there
#
# usage: addcr < infile > outfile && mv outfile infile
#
while ($line = <STDIN>) {
    chop($line);
    if ($line =~ /\r$/) {
	print "$line\n";
    } else {
    	print "$line\r\n";
    }
}

#!/usr/bin/perl
# replace MacOS pathname for Eudora attachments with Windows pathname
#
# usage: reattach < infile > outfile && mv outfile infile
#
# the regexp matches "Mark’s HD:" followed by anything up to a (
# the text between "Mark’s HD:" and the paren is the filename only
# and gets inserted at the end of the Windows pathname; a trailing
# space is removed so the quotes surrounding the pathname are just
# the text without trailing space

while (<STDIN>) {
    s/Mark's HD:([^(]*)\(/"C:\\Program Files\\Qualcomm\\Eudora Mail\\Attach\\$1"\(/g;
    s/ "\(/" (/g;
    print;
}