[R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[McGrath, Justin M]

The maximum path length supported by ustar is 255 bytes, and any path compatible with ustar is compatible with path limits for all file systems used by any operating system for the last several decades. Anything that is ustar compatible is compatible with all other requirements. There is no reason today to reject packages with ustar compatible paths that are not v7 compatible.

Best wishes,
Justin

________________________________________
From: Tomas Kalibera <tomas.kalibera using gmail.com>
Sent: Wednesday, December 13, 2023 8:32 AM
To: McGrath, Justin M; Ben Bolker; Martin Maechler; r-package-devel using r-project.org
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

On 12/13/23 14:56, McGrath, Justin M wrote:
>> Thanks. Pursuing this a bit further, from ?tar "Known problems":
>      > The handling of file paths of more than 100 bytes.  These
>      > were unsupported in early versions of ‘tar’, and supported in
>      > one way by POSIX ‘tar’ and in another by GNU ‘tar’ and yet
>      > another by the POSIX ‘pax’ command which recent ‘tar’
>      > programs often support.  The internal implementation warns on
>      > paths of more than 100 bytes, uses the ‘ustar’ way from the
>      > 1998 POSIX standard which supports up to 256 bytes (depending
>      > on the path: in particular the final component is limited to
>      > 100 bytes) if possible, otherwise the GNU way (which is
>      > widely supported, including by ‘untar’).
>
> R CMD check --as-cran gives a WARNING if a path is not ustar compatible, and gives the same message as a NOTE if it is not v7 compatible.
>
> The path in the example below is ustar compatible, but not v7 compatible.
>
> ***********
> * checking for portable file names ... NOTE
> Found the following non-portable file path:
>    BioCro/inc/boost/numeric/odeint/stepper/generation/generation_controlled_adams_bashforth_moulton_really_long_file_name_one_two_three.hpp
>
> Tarballs are only required to store paths of up to 100 bytes and cannot
> store those of more than 256 bytes, with restrictions including to 100
> bytes for the final component.
> ***********
>
> The code is in library/tools/R/check.R. An equivalent test is performed by R CMD build in library/tools/utils/tar.R.
>
> AFAIK, CRAN rejects a package regardless whether the message is given as a NOTE or a WARNING. ustar is 35 years old and is older than R itself, and thus anyone using R in the last several decades will have ustar support. Any path stored by ustar will be suitable for any common file system in use for the last several decades. Overall, if a path is supported by ustar, there is no reason to generate any message, even if that path is not v7 compatible. If the NOTE about v7 incompatibility is still desired, then could CRAN not reject packages for which the check reports a NOTE?

Please don't forget about what has been correctly mentioned on this
thread already: there is essentially a 260 character limit on Windows
(see
https://urldefense.com/v3/__https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html__;!!DZ3fjg!-9O1ZyZet_W6lAzZI0JZDI27SKTG6H4M4E5zB9xFItNpCD-I-eH2xmFxJ10uU1WAy1JNb4EiygQzkDsHkO1chmsk4TKd$
for more). Even if the relative path length limit for a CRAN package was
no longer regarded important for tar compatibility, it would still make
sense for compatibility with Windows. It may still be a good service to
your users if you keep renaming the files to fit into that limit.

Also please do not share private emails on the list.

Thanks
Tomas

>
> Best wishes,
> Justin
>
>
> _