cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (02/02/88)
This one is pretty serious - I'm not sure what we were thinking at the time. There was no excuse for making the finderinfo files system dependent. bug reports 0001 through 0015 for CAP distribution 4.00 + patches 5,6,7 are available via anonymous ftp to cu20b.columbia.edu as us:[us.cck.cap.d4]bug1-15.shar. Charlie C. Kim User Services Columbia University CAP Pre-Release Distribution 4.00 with Patches 5,6,7 Bug Report: 0015 Date: 2/1/88 Problem: Aufs .ADeskTop, .IDeskTop and .finderinfo files are NOT transportable across byteswapped/non-byteswapped machines. Reported by: Charlie C. Kim Priority: High Diagnosis: In coding the desktop and finderinfo routines, we failed to properly take into account byte-swapping when writing out these files. Thus, NFS cross-mounts and other transfers between such machines will not work properly. In particular, the DeskTop files will be completely unusable. Only the file attributes in the .finderinfo files will be affected: these are the flags indicating whether the file is: Read-Only, Invisible or Multi-User (other flags are on open-files: RAlreadyOpen, DAlready-Open). Solution: For the .ADeskTop and .IDeskTop, simply recode (simple) and change the magic numbers. The new code will truncate .IDeskTop and .ADeskTop if they are invalid. The effect for end users is that they will need to rebuild their desktops. The .finderinfo files are a bigger problem. The solution will take the form of modifying the .finderinfo format to contain version information and making Aufs accept both file formats. The new code will rewrite the old finderinfo files whenever it sees them. (Rebuilding the desktop for above will take care of it). NOTE: THE NEW VERSION OF AUFS WILL NOT BE BACKWARD COMPATIBLE WITH THE OLD ONE. The old (current) version of Aufs, due to design flaws, cannot tell if the .finderinfo files are out of revision. The new version of Aufs will be able to tell. In addition, we should note that we've discovered a bug in the file information code. Basically, it interpreted the set file attribute call incorrectly and would not allow clearing of the invisible, multi-user, and read-only flags. We will not support the AppleSingle/AppleDouble formats at the present time for the following reasons: o AppleSingle is not well-oriented towards the needs of Aufs or any file server. It is a transporting mechanism. o AppleDouble has a number of problems for a file server. Namely: - some semantic problems that arise because the resource fork is not in a seperate file (byte range lock, seeks, etc.) - considerably higher overhead due to the name scheme enforced and the semantic problems o Finally, the format is a moving target at the present time - the draft proposal shown has had a number of revisions made that we are not privy to. We were avoiding modifying the .finderinfo file format until such time as we had made a final decision on whether to support the AppleDouble format; however, this problem is major enough to force changes. We apologize.