[R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?
Hi, when trying to update my package on CRAN it is rejected, because it gets a note during checks on Debian: Flavor: r-devel-linux-x86_64-debian-gcc Check: for non-standard things in the check directory, Result: NOTE Found the following files/directories: 'NUL' There is no such file in my folder and therefore it can't be removed. With Windows everything is OK. As far as I understood, this is a problem with Rhub? (https://github.com/clessn/locateip/issues/99) Or what can I do, to fix this problem and get my package update submitted to CRAN? Thanks, Friedemann von Lampe __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?
Dear Friedemann von Lampe, Welcome to R-package-devel! This is a good, concise description of the problem, but please also provide a link to your code in the future. В Wed, 13 Dec 2023 09:58:41 +0100 Friedemann von Lampe пишет: > Flavor: r-devel-linux-x86_64-debian-gcc > Check: for non-standard things in the check directory, Result: NOTE > Found the following files/directories: > 'NUL' The file named 'NUL' is created in the function screeplot_NMDS: R/screeplot_NMDS.R: capture.output(nmds_i <- invisible(metaMDS(matrix, distance = distance, k = i, trymax = trymax, engine = "monoMDS", autotransform = autotransform)), file='NUL') https://github.com/fvlampe/goeveg/blob/db94c4a567eeac67b6df1df5a4f2d1aa771e629a/R/screeplot_NMDS.R#L76 On Windows, everything goes right and the output is redirected to the null device. On Linux, the null device is '/dev/null', not 'NUL', and this name doesn't hold any special powers, so the file with this name gets created. Use the base function nullfile() to obtain the name of the null device in a portable manner. I think you can also not supply the `file` argument and ignore the return value of the capture.output(...) expression. This may be less efficient if there's truly a lot of output. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
> 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? Best wishes, Justin From: Martin Maechler Sent: Wednesday, December 13, 2023 2:22 AM To: Ben Bolker; McGrath, Justin M Cc: Simon Urbanek; Duncan Murdoch Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted? > Ben Bolker > on Tue, 12 Dec 2023 15:48:11 -0500 writes: > 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’). > This issue is reminiscent of the "invalid uid value replaced ..." > warning, which has happened to me a lot but which CRAN has never > actually flagged when I've submitted a package: > https://urldefense.com/v3/__https://stackoverflow.com/questions/30599326/warning-message-during-building-an-r-package-invalid-uid-value-replaced-by-that__;!!DZ3fjg!7eG1psjusIaxJny-wr4z56esZliTkCKpBunUO0IPxzllvu3oSRehH6ZnQh8vJN6ZkaAAmNXHaAHfrqwULOipdsJh2VOFww$ > (By the way, this thread now seems firmly on-topic for r-pkg-devel, > even if the ultimate answers must come from the CRAN maintainers ...) Well, yes, in parts at least. Originally, even when it did not seem clear, it mostly seemed about the part of the help(tar) page you mention above and the implementation of tar() .. i.e. R-devel. ... but it's not really important anymore now, and hence this goes only to you. Best regards, Martin > cheers > Ben > On 2023-12-12 3:41 p.m., Duncan Murdoch wrote: >> I don't know what the warning looks like, but the ?tar help page >> discusses the issues. >> >> Duncan Murdoch >> >> On 12/12/2023 3:10 p.m., Ben Bolker wrote: >>>FWIW the R-windows FAQ says: >>> >>> Yet another complication is a 260 character limit on the length of the >>> entire path name imposed by Windows. The limit applies only to some >>> system functions, and hence it is possible to create a long path using >>> one application yet inaccessible to another. It is sometimes possible to >>> reduce the path length by creating a drive mapping using subst and >>> accessing files via that drive. As of Windows 10 version 1607 and R 4.3, >>> one can remove this limit via Windows registry by setting >>> Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
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://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html 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 _ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?
Rhub is not CRAN. Please include a link to your source package if you want help. If there is actually a bug in Rhub then this NUL error may not reflect the response you will get from CRAN if and when you submit. On December 13, 2023 12:58:41 AM PST, Friedemann von Lampe wrote: >Hi, > >when trying to update my package on CRAN it is rejected, because it gets a >note during checks on Debian: > >Flavor: r-devel-linux-x86_64-debian-gcc >Check: for non-standard things in the check directory, Result: NOTE >Found the following files/directories: >'NUL' > >There is no such file in my folder and therefore it can't be removed. With >Windows everything is OK. >As far as I understood, this is a problem with Rhub? >(https://github.com/clessn/locateip/issues/99) > >Or what can I do, to fix this problem and get my package update submitted to >CRAN? > >Thanks, >Friedemann von Lampe > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
On 13 December 2023 at 15:32, Tomas Kalibera wrote: | 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://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html | 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. So can lift the limit from 100 char to 260 char ? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
On 12/13/23 15:59, Dirk Eddelbuettel wrote: On 13 December 2023 at 15:32, Tomas Kalibera wrote: | 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://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html | 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. So can lift the limit from 100 char to 260 char ? The 260 char limit is for the full path. A package would be extracted in some directory, possibly also with a rather long name. Tomas Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
On 13 December 2023 at 16:02, Tomas Kalibera wrote: | | On 12/13/23 15:59, Dirk Eddelbuettel wrote: | > On 13 December 2023 at 15:32, Tomas Kalibera wrote: | > | 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://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html | > | 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. | > | > So can lift the limit from 100 char to 260 char ? | | The 260 char limit is for the full path. A package would be extracted in | some directory, possibly also with a rather long name. Call a cutoff number. Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and then commit the change. N = 50 would be a great start as arbitrary as it is. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
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 Sent: Wednesday, December 13, 2023 8:32 AM To: McGrath, Justin M; Ben Bolker; Martin Maechler; r-package-devel@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 > > > _ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
I'm not even asking for that. I'm asking for the decades old ustar comparability, which is 255 characters, at most. In practice it is slightly less than that. ustar is older than R itself. There is no one using R who doesn't have ustar compatible tar. From: Dirk Eddelbuettel Sent: Wednesday, December 13, 2023 8:59 AM To: Tomas Kalibera Cc: McGrath, Justin M; Ben Bolker; Martin Maechler; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted? On 13 December 2023 at 15:32, Tomas Kalibera wrote: | 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!-YZg5PVpulgNXCVfVklP442UG_0ofB8omMLlMq5dNadF9RP_6uofnrT6IbZpG1fpvjmAtLyAm1Y9rbc$ | 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. So can lift the limit from 100 char to 260 char ? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
On Windows, packages will be in "C:\Users\[User Name]\Documents\R\win-library\[R version]\[Package Name]". With a 150 byte limit, that leaves 70 bytes for the user name, R version and package name. That seems more than sufficient. If people are downloading the source files, that also leaves plenty of space regardless where they choose to extract the files. From: Dirk Eddelbuettel Sent: Wednesday, December 13, 2023 9:13 AM To: Tomas Kalibera Cc: Dirk Eddelbuettel; McGrath, Justin M; Ben Bolker; Martin Maechler; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted? On 13 December 2023 at 16:02, Tomas Kalibera wrote: | | On 12/13/23 15:59, Dirk Eddelbuettel wrote: | > On 13 December 2023 at 15:32, Tomas Kalibera wrote: | > | 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!-NHAlEZQvY2kegkNVkuY3Lf84nKmMahrpZ4Euz2XXFDPvMWEcP28iepLlRiKzVZdAh752lyhHxd6zvk$ | > | 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. | > | > So can lift the limit from 100 char to 260 char ? | | The 260 char limit is for the full path. A package would be extracted in | some directory, possibly also with a rather long name. Call a cutoff number. Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and then commit the change. N = 50 would be a great start as arbitrary as it is. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
This is a narrow view of the world. As has been mentioned here by Tomas, the issue at this point is that a very widely-used operating system does not allow the absolute path to be longer than 254 characters unless users make possibly-breaking changes to their OS configuration. If a user is currently working in a directory with a path that is 150 characters long, and you try to un-tar a package there, it will work. If they are in a directory path that is 170 characters long, then the un-tar will fail. They then have to do some research and discover that they have to share the total absolute path length with the package creators, and they become accustomed to working in directories with path length no longer than 154 characters. Now you want to propose giving the entire path length budget plus 2 to the package developers. Not gonna happen. And Dirk wants 50 more characters. Then the user working at 150 characters tries to un-tar a package with paths 150 characters long and 150 user plus 150 package gets you to 300 characters and what used to work for them stops working suddenly. I think a package developer can figure out how to shorten their internal paths easier than thousands of users can restructure their historically useful directory structures or break their existing software. I vote no to both of these proposals. Eventually, Microsoft is going to virtualize running old Windows APIs, and once people migrate away from the old API then this stupid problem will go away. But as it is we are stuck. On December 13, 2023 7:27:42 AM PST, "McGrath, Justin M" wrote: >I'm not even asking for that. I'm asking for the decades old ustar >comparability, which is 255 characters, at most. In practice it is slightly >less than that. ustar is older than R itself. There is no one using R who >doesn't have ustar compatible tar. > > >From: Dirk Eddelbuettel >Sent: Wednesday, December 13, 2023 8:59 AM >To: Tomas Kalibera >Cc: McGrath, Justin M; Ben Bolker; Martin Maechler; >r-package-devel@r-project.org >Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length >limit be lifted? > > >On 13 December 2023 at 15:32, Tomas Kalibera wrote: >| 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!-YZg5PVpulgNXCVfVklP442UG_0ofB8omMLlMq5dNadF9RP_6uofnrT6IbZpG1fpvjmAtLyAm1Y9rbc$ >| 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. > >So can lift the limit from 100 char to 260 char ? > >Dirk > >-- >dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
On Wed, Dec 13, 2023 at 8:06 AM McGrath, Justin M wrote: > > On Windows, packages will be in "C:\Users\[User > Name]\Documents\R\win-library\[R version]\[Package Name]". In R (>= 4.2.0), the default R_LIBS_USER path has moved to under LOCALAPPDATA, e.g. "C:\Users\[User Name]\AppData\Local\R\win-library\[R version]". See https://cran.r-project.org/bin/windows/base/rw-FAQ.html FWIW, one workaround for too long paths on MS Windows is to map a long path to a drive letter, e.g. subst Y: 'C:/VeryLongPathToo/Users/JohnDoe/AppData/Local/R/'. and then work with Y: instead of C:. We had to use that in some projects with nested data folder structures. This approach is tedious, and might require special permissions (not sure). /Henrik > > With a 150 byte limit, that leaves 70 bytes for the user name, R version and > package name. That seems more than sufficient. If people are downloading the > source files, that also leaves plenty of space regardless where they choose > to extract the files. > > > From: Dirk Eddelbuettel > Sent: Wednesday, December 13, 2023 9:13 AM > To: Tomas Kalibera > Cc: Dirk Eddelbuettel; McGrath, Justin M; Ben Bolker; Martin Maechler; > r-package-devel@r-project.org > Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length > limit be lifted? > > > On 13 December 2023 at 16:02, Tomas Kalibera wrote: > | > | On 12/13/23 15:59, Dirk Eddelbuettel wrote: > | > On 13 December 2023 at 15:32, Tomas Kalibera wrote: > | > | 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!-NHAlEZQvY2kegkNVkuY3Lf84nKmMahrpZ4Euz2XXFDPvMWEcP28iepLlRiKzVZdAh752lyhHxd6zvk$ > | > | 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. > | > > | > So can lift the limit from 100 char to 260 char ? > | > | The 260 char limit is for the full path. A package would be extracted in > | some directory, possibly also with a rather long name. > > Call a cutoff number. > > Any move from '100' to '100 + N' for any nonzero N is a win. Pick one, and > then commit the change. N = 50 would be a great start as arbitrary as it is. > > Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to fix: non-standard things in the check directory: 'NUL' ?
Thanks. Thankfully Ivan looked up the source package (https://github.com/fvlampe/goeveg) and his response previously on this list solved the problem for CRAN. I simply needed to change the argument from 'NUL' to NULL. The package was now successfully submitted. However, in R-hub the NOTE remains, which apparently is is one of their problems. Am 13.12.2023 um 15:55 schrieb Jeff Newmiller via R-package-devel: Rhub is not CRAN. Please include a link to your source package if you want help. If there is actually a bug in Rhub then this NUL error may not reflect the response you will get from CRAN if and when you submit. On December 13, 2023 12:58:41 AM PST, Friedemann von Lampe wrote: Hi, when trying to update my package on CRAN it is rejected, because it gets a note during checks on Debian: Flavor: r-devel-linux-x86_64-debian-gcc Check: for non-standard things in the check directory, Result: NOTE Found the following files/directories: 'NUL' There is no such file in my folder and therefore it can't be removed. With Windows everything is OK. As far as I understood, this is a problem with Rhub? (https://github.com/clessn/locateip/issues/99) Or what can I do, to fix this problem and get my package update submitted to CRAN? Thanks, Friedemann von Lampe __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
