From: didier <dga...@ma...> - 2009-07-16 11:43:28
|
Le mardi 30 juin 2009 à 19:14 +0200, Frank Lahm a écrit : > 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. Does it still use 17 for "Network Trash Folder"? We need it for compatibility with OS9. > > If you think it's beneficial I can also add the functionality to dbd > to adjust any cnid between 17 and 0xffff ? I don't think we need it, it may create more problems than it solves some applications do stupid things with cnid. Affected user on old volumes can rm the DB. Didier |