Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

Hi Philippe,

On Jun  6 03:14, Philippe Cerfon wrote:
> Hey Corinna, et al.
> 
> On Mon, Jun 5, 2023 at 9:05 PM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > - Whatever that's good for, we actually allow bigger values right
> >   now.  For compat reasons we only allow attributes starting with
> >   the "user." prefix, and the *trailing* part after "user." is
> >   allowed to be 255 bytes long, because we don't store the "user."
> >   prefix in the EA name on disk.  So in fact, XATTR_NAME_MAX should
> >   be 255 + strlen("user.") == 260.
> 
> I haven't given to much though into that right now (just about to go
> for 2 weeks on vacation), but if "we" (Cygwin) allow now names up to
> 260 bytes, because we don't store the "user." .. doesn't that mean
> users could set XATTRs, that in the end couldn't be read by e.g. Linux
> (should there be, or ever be in the future, support for reading
> FAT/NTFS' EAs as XATTRs.... e.g. from the Linux FAT/NTFS fs drivers)?

No, that's no problem.  The names on disk are actually just 255 chars
long, so the Linux kernel will handle them just fine.  It's only Cygwin
which should expose 260 chars to user space to emulate the "user."
prefix.

> > - If we actually define these values in limits.h, it would also be a
> >   good idea to use them in ntea.cc and to throw away the MAX_EA_*_LEN
> >   macros.
> 
> Done so in a 2nd commit.
> But that commit, right now, really just replaces the name!
> MAX_EA_NAME_LEN was set 256, so presumably with the null terminator...
> while now it would be set to 260, which seems wrong.

Yes, it is wrong, because the value of MAX_EA_NAME_LEN / XATTR_NAME_MAX
is used for array size definitions as well as comparisons.

> Please just adapt if necessary,... or at least I won't likely be able
> to update the patch until in about 2 weeks or so.

No worries, we're in no hurry.


Thanks,
Corinna