|< Day Day Up >|
If you're going to move files between your Mac and another operating system, there are some things you need to watch out for. As we discussed in Chapter 2, the Apple Double format will sprinkle some files with odd names across the filesystem, such as ._filename. You'll also find a few files created in the root, such as Temporary Items and .Trashes (see Table 3-1).
The most significant problem you'll run into is moving large files around: if you're not using a third-party utility, the only common filesystem that Mac OS X, Windows, and Linux can read and write is the ancient FAT32, which has a limit of 2 GB per file.
If at all possible, we suggest that you use the network to transfer large files. If you're using an AirPort (or even a 100BaseT) network, it's worth running a cable between your Mac and the other system and setting up a TCP/IP connection for large file transfers. If you can get Gigabit Ethernet or even IP over FireWire, you'll be pleased with the zippy file transfer speeds. Even if you're not moving large files, the network is often the best way to exchange information. The are several solutions you can use for exchanging files across the network:
If you use multiple solutions in combination, you may run into trouble if they disagree with what's going on under the hood of their Apple Double implementation. For example, suppose you have a single Internet location (.webloc) file in the ~/Test directory on your Mac:
$ cd Test/ $ ls -l total 8 -rw-r--r-- 1 bjepson bjepson 0 Mar 5 13:38 Safari.webloc
Next, suppose you sync your Mac to a Linux server using Unison:
$ unison /Users/bjepson/Test ssh://firstname.lastname@example.org//home/bjepson/Test Contacting server... Password: ******** Looking for changes Waiting for changes from server Reconciling changes local homer new file ----> Safari.webloc [f] Proceed with propagating updates?  y Propagating updates UNISON started propagating changes at 14:21:13 on 05 Mar 2005 [BGN] Copying Safari.webloc from /Users/bjepson/Test to //homer//home/bjepson/Test [END] Copying Safari.webloc UNISON finished propagating changes at 14:21:13 on 05 Mar 2005 Saving synchronizer state Synchronization complete (1 item transferred, 0 skipped, 0 failures)
If you log into the Linux server and inspect the filesystem, you'll see the same kind of Apple Double file format that's used by Mac OS X. All is well with the world:
$ ls -al total 12 drwxr-xr-x 2 bjepson bjepson 4096 2005-03-05 14:21 . drwxr-xr-x 39 bjepson bjepson 4096 2005-03-05 14:18 .. -rw------- 1 bjepson bjepson 741 2005-03-05 14:21 ._Safari.webloc -rw-r--r-- 1 bjepson bjepson 0 2005-03-05 14:21 Safari.webloc
Now, suppose this directory on the Linux server is also shared using Netatalk's afpd. Things would get weird if you created another Internet location file on the Mac, and then used the Finder to drag and drop that file across to the AFP share on the Linux box.
Netatalk is going to do a couple of surprising things. First, when it creates a dot file such as .DS_Store, it does a hexadecimal conversion and creates :2eDS_Store. Second, instead of creating a file that adheres to the Apple Double format used by Apple and Unison, it's going to create a .AppleDouble directory that contains the metadata that HFS+ would normally store transparently. Here's what you've got on the Linux side now:
$ ls -al total 36 drwxr-xr-x 3 bjepson bjepson 4096 2005-03-05 14:34 . drwxr-xr-x 40 bjepson bjepson 4096 2005-03-05 14:34 .. -rw-r--r-- 1 bjepson bjepson 6148 2005-03-05 14:34 :2eDS_Store drwxr-xr-x 2 bjepson bjepson 4096 2005-03-05 14:34 .AppleDouble -rw-r--r-- 1 bjepson bjepson 6148 2005-03-05 14:26 .DS_Store -rw-r--r-- 1 bjepson bjepson 254 2005-03-05 14:23 Google.webloc -rw------- 1 bjepson bjepson 741 2005-03-05 14:21 ._Safari.webloc -rw-r--r-- 1 bjepson bjepson 0 2005-03-05 14:21 Safari.webloc $ ls -l .AppleDouble/ total 8 -rw-rw-rw- 1 bjepson bjepson 741 2005-03-05 14:34 :2eDS_Store -rw-rw-rw- 1 bjepson bjepson 1191 2005-03-05 14:34 Google.webloc
As you might imagine, the next time you run Unison from the Mac side, all hell breaks loose. Unison is forced to skip two files:
$ unison /Users/bjepson/Test ssh://email@example.com//home/bjepson/Test Contacting server... Password: Looking for changes Safari.webloc Waiting for changes from server Reconciling changes local homer error .AppleDouble [root 2]: The name of this Unix file is not allowed in Windows/OSX (. AppleDouble/:2eDS_Store) error :2eDS_Store The name of this Unix file is not allowed in Windows/OSX (:2eDS_Store) new file ====> new file Google.webloc  > changed ----> .DS_Store [f] Proceed with propagating updates?  y Propagating updates UNISON started propagating changes at 14:36:39 on 05 Mar 2005 [ERROR] Skipping .AppleDouble [root 2]: The name of this Unix file is not allowed in Windows/OSX (. AppleDouble/: 2eDS_Store) [ERROR] Skipping :2eDS_Store The name of this Unix file is not allowed in Windows/OSX (:2eDS_Store) [BGN] Updating file Google.webloc from /Users/bjepson/Test to //homer//home/bjepson/Test [BGN] Updating file .DS_Store from /Users/bjepson/Test to //homer//home/bjepson/Test [END] Updating file .DS_Store [END] Updating file Google.webloc UNISON finished propagating changes at 14:36:39 on 05 Mar 2005 Saving synchronizer state Synchronization complete (2 items transferred, 2 skipped, 0 failures) skipped: .AppleDouble skipped: :2eDS_Store
We'd suggest that you only use one point of entry (either Unison or Netatalk) for a given directory, but if you need to have it both ways, there are solutions.
One workaround is to add options:ro,noadouble to the filesystem's entry in AppleVolumes.default on the Linux server. This makes the AFP share read-only and also disables the creation of .AppleDouble (except when a resource fork is created, which won't happen because you're accessing it read-only). This gives you quick and dirty access to the files on the Linux server via AFP when you need it, but forces you to update them through only Unison.
Another solution is to keep everything read/write, mount the remote server's filesystem before you run Unison, and simply have Unison treat the remote server as a local filesystem instead of going through SSH:
$ unison /Users/bjepson/Test /Volumes/Home\ Directory/Test
You'll still have crufty files (such as :2eDS_Store) appear on the Linux side, but they won't get in the way when you synchronize files and folders. However, this is a suboptimal configuration for Unison, which benefits greatly from having local filesystem access to the files on both ends of the synchronization.
|< Day Day Up >|