wilson@csli.Stanford.EDU (Nathan Wilson) (02/23/90)
I recently got DiskTop (version 4.0) and discovered a potentially nasty interaction between it and AUFS volumes. We have AUFS configured so that for files of type TEXT, it automatically maps carriage return to linefeed when going from the mac to the unix host and back when going the other direction. This is all well and good and works great from the finder. It also works great with DiskTop when you copy from the unix host to the mac or if you overwrite a file on the unix host. The problem arises when you try to write a new file on to the unix host from the mac. The character translation doesn't happen. My guess as to what's happening is that DiskTop first writes the contents of the file and then the finderinfo. Thus AUFS has no way of figuring out that the file requires character translation so it doesn't happen. After formulating this theory I realized that it implied an even worse more subtle bug. Imagine you have a text file on the AUFS volume and you go to write over it with a file of a different type (say an application or some binary data) but the same name. If DiskTop waits to send the finderinfo, then AUFS will corrupt the binary data as it comes across. I tested this and found that the resource fork is not corrupted, but the data fork is. The resource fork is presumably untouched by AUFS, since it only makes sense to do character mapping on the data fork. The fix: If the file doesn't already exist on the unix host with the correct finderinfo, copy the file twice. It's a little tricky figuring out whether this is a bug in AUFS or in DiskTop. My personal opinion is that it's a bug in DiskTop for the following reasons: 1) DiskTop's copying mechanism should be exactly equivalent or a superset of the finder's copying mechanism. 2) The character translation that AUFS does is perfectly legitimate since it maintains the *semantics* of a file. The problem is the semantics of ascii 10 and ascii 13 depend on the type of the file, thus the finderinfo fork should be written before anything else. Does Apple have anything to say about this? Nathan Wilson Teleos Research nathan@teleos.com