Re: [Netatalk-devel] cannot copy long filename including #hex

[didier <dga...@ma...>]

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