From: Frank L. <fra...@go...> - 2009-06-30 17:14:48
|
Hi, 2009/6/30 HAT <ha...@fa...>: > Hi, > > 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. If you think it's beneficial I can also add the functionality to dbd to adjust any cnid between 17 and 0xffff ? -Frank |