From: Frank L. <fra...@go...> - 2009-07-20 11:55:12
|
2009/7/16 Frank Lahm <fra...@go...>: > 2009/7/16 didier <dga...@ma...>: >> Le mardi 30 juin 2009 à 19:14 +0200, Frank Lahm a écrit : >>> 2009/6/30 HAT <ha...@fa...>: >>> > On *20 Dec 2008 07:01:33 +0100* >>> > didier <dga...@ma...> wrote: >>> > >>> >> Le vendredi 19 décembre 2008 à 02:08 +0900, HAT a écrit : >>> >> > 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). >>> >>> Afaik that doesn't prevent a collision on OS X if the file "matched" >>> by the #<id> is not in the share. I.e. netatalk and OS X suffer the >>> same. >>> >>> >> For a user 'foo item #1000.txt' can look like a sensible name, >>> >> 'foo item #4BDF.txt' a little less :) >>> > >>> > I wrote a patch. >>> > >>> > -#define CNID_START 17 >>> > +#define CNID_START_SPEC 17 >>> > +#define CNID_START 0x10000 >>> > >>> > Please see a attached file. >>> > >>> > In case of existing volume, (new CNID) is (last CNID)+1. >>> > In case of new volume, CNID begins at 0x10001. >>> > >>> > This is not a perfect method. >>> > However, I think it is safe enough. >>> >>> I'm not sure if I like the idea of introducing a hack for a bug, but >>> in the end it might be the cleanest thing to do. >> >> Does it still use 17 for "Network Trash Folder"? We need it for >> compatibility with OS9. > > I guess, I have to test it though. As it seems only raising CNID_START is not enough because as suggested by Didier "Network Trash Folder" wont be assigned CNID 17: $ s dbd -d /Volumes/CNID/ CNID database dump: dbd stamp: 0x4a645a11 (Jul 20 2009 13:50:41), next free CNID: 65542 id: 65537, did: 2, type: f, dev: 0x41, ino: 0x000000000fcec120, name: .DS_Store id: 65538, did: 2, type: d, dev: 0x41, ino: 0x000000000fcec084, name: Network Trash Folder id: 65539, did: 2, type: d, dev: 0x41, ino: 0x000000000fcec08a, name: Temporary Items id: 65540, did: 2, type: d, dev: 0x41, ino: 0x000000000fe5801a, name: dir id: 65541, did: 2, type: d, dev: 0x41, ino: 0x000000000ed24002, name: netatalk-docs 5 CNIDs in database. Max CNID: 65541. -Frank |