public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Philippe Cerfon <philcerf@gmail.com>
Cc: cygwin-patches@cygwin.com, Brian Inglis <Brian.Inglis@shaw.ca>
Subject: Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
Date: Mon, 5 Jun 2023 21:05:50 +0200	[thread overview]
Message-ID: <ZH4yDkPXLU9cYsrn@calimero.vinschen.de> (raw)
In-Reply-To: <f4106af5-ed7a-0df5-a870-b87bb729f862@Shaw.ca>

[dropping newlib from the recipient list]

Hi Philippe,

On May 30 14:04, Brian Inglis wrote:
> On Tue, 30 May 2023 13:25:38 +0200, Philippe Cerfon wrote:
> > Hey there.
> > 
> > Linux exports XATTR_{NAME,SIZE,LIST}_MAX in it's linux/limits.h and
> > e.g. the CPython interpreter uses them for it's XATTRs functions.
> > 
> > I made a corresponding PR at CPython
> > https://github.com/python/cpython/pull/105075 to get the code built
> > for Cygwin, but right now this would fail due to the missing
> > XATTR_*_MAX symbols.
> > 
> > The attached patch below would add them to cygwin/limits.h.
> 
> Patches for Cygwin under winsup are submitted to cygwin-patches@cygwin.com
> (forwarded there).
> 
> > But beware, I'm absolutely no Windows/Cygwin expert ^^ - so whether
> > the values I've chosen are actually correct, is more guesswork rather
> > than definite knowledge.
> > 
> > As written in the commit message, I think:
> > - XATTR_NAME_MAX corresponds to MAX_EA_NAME_LEN
> > and
> > - XATTR_SIZE_MAX to MAX_EA_VALUE_LEN
> > 
> > though I have no idea, whether these are just lower boundaries used by
> > Cygwin, while e.g. Windows itself might set longer names or value
> > lenghts, and thus - when Cygwin would try to read such - it might get
> > into troubles (or rather e.g. CPython, as it's buffers wouldn't
> > suffice to read the EA respectively XATTR.

As on Linux, these are upper bounds of the kernel API. In case of
MAX_EA_VALUE_LEN that's especially true, because the defined API
isn't overly consistent: the datastructure allows bigger values
than the function calls are able to handle.  However, file systems
may impose lower limits without them having matching macros.
IIRC, an EA on ext4 may be only 4K, but I'm not entirely sure.

Either way, we can do what you propose, but...

- The XATTR_NAME_MAX value is incorrect. The MAX_EA_NAME_LEN value
  is an internal definition for a name *including* the trailing \0,
  the XATTR_NAME_MAX value defines the max name length *excluding*
  the trailing \0.  Compare with NAME_MAX.

- 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.

- 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.

A patch along these lines is appreciated.


Thanks,
Corinna

  reply	other threads:[~2023-06-05 19:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAN+za=MhQdD2mzYxqVAm9ZwBUBKsyPiH+9T5xfGXtgxq1X1LAA@mail.gmail.com>
2023-05-30 20:04 ` Brian Inglis
2023-06-05 19:05   ` Corinna Vinschen [this message]
2023-06-06  1:04     ` Philippe Cerfon
2023-06-06  1:14     ` Philippe Cerfon
2023-06-06 13:28       ` Corinna Vinschen
2023-06-06 15:17         ` Philippe Cerfon
2023-06-07 10:06           ` Corinna Vinschen
2023-06-16 14:09             ` Philippe Cerfon
2023-06-16 15:04               ` Corinna Vinschen
2023-06-16 15:43                 ` Philippe Cerfon
2023-06-16 19:49                   ` Corinna Vinschen
2023-06-16 19:52                     ` Philippe Cerfon
2023-06-19  8:53                       ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZH4yDkPXLU9cYsrn@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=Brian.Inglis@shaw.ca \
    --cc=cygwin-patches@cygwin.com \
    --cc=philcerf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).