From: didier <dga...@ma...> - 2008-12-20 06:01:20
|
Le vendredi 19 décembre 2008 à 02:08 +0900, HAT a écrit : > Hi, > > The following filenames can be copied from Mac OS X to netatalk. > > aaa#11.txt > bbb#12.txt > ccc#13.txt > > But, the following filenames might not be able to be copied. > > aaaaaaaaaaaaaaaaaaaaaa#11.txt > bbbbbbbbbbbbbbbbbbbbbb#12.txt > cccccccccccccccccccccc#13.txt > > This problem happens even if using either Finder or cp command > in Terminal.app. > > Finder's Error Message: > > > > >The Finder cannot complete the operation because some data > >in "aaaaaaaaaaaaaaaaaaaaaa#11.txt" could not be read or > >written. > >(Error code -36) > > > > cp command's Error Message: > > > > ># cp aaaaaaaaaaaaaaaaaaaaaa#11.txt /Volumes/neta-vol/dir/ > >cp: /Volumes/neta-vol/dir/aaaaaaaaaaaaaaaaaaaaaa#11.txt: Is a directory Yep, in the spec 11 hexa is the old OS9 'Network Trash Folder'. > > > > If filename is long and include #hex, Mac OS X request FPGetFileDirParms > and FPResolveID command. > > When there is a directory of the same CNID as #hex on netatalk's volume, > netatalk return kFPObjectTypeErr to FPResolveID, and the copy fails. > (See osx105-neta21dev.dump) > > Mac OS X return kFPIDNotFound to FPResolveID, and the copy succeeds. > (See osx105-osx104.dump) > > #0 - #10 are no problem because these CNID is reserved. > > Netatalk's result code is more right than Mac OS X. > However, netatalk should behave as well as Mac OS X. > I wrote a one-line patch. > (netatalk-2.1dev-resolveid_dir.patch) Thanks, I'll try to do more tests because in the test suite we specifically test for both values, meaning that at least some Apple server versions (pre OSX?) were returning kFPObjectTypeErr and it's the kind of stuff where returning the wrong value can badly confuse a client in weird places. After these tests I think I will put something like: if (afp_version < 3) return kFPObjectTypeErr else kFPIDNotFound. > Still another problem exists. > When a file or directory of the same CNID as #hex is in the distination > directory, the following message is displayed. > > > > >A newer item named "xxxxxxxxxxxxxxxxxxxxxxxx" already exists in > >this location. Do you want to replace it with the older one you > >are moving? > > [Stop] [Replace] > > > > If "Replace" is clicked, this file or directory is overwrited, > though it is another filenmame. > This problem occur on both netatalk and Mac OS X. > Mac OS X is defective. > I think there is no countermeasure. I agree. This problem is worse with netatalk because volumes export low cnid numbers. On a Mac system these low numbers are more likely to be used by unshared files (system files, whatever). For a user 'foo item #1000.txt' can look like a sensible name, 'foo item #4BDF.txt' a little less :) Didier |