bug#70586: cp walks dir differently than rm and is hitting "File name too long" where this could be avoided

Paul Eggert <[email protected]> writes:

> On 10/15/25 09:36, Collin Funk wrote:
>> I'll have a look at that one too. Finding a reasonable way to define the
>> sort functions in terms of 'FTSENT **' will not be very fun though.
>
> Should be easier for ls than for cp, as fts isn't really designed for
> destinations so you'll have to traverse the destination by hand.

I thought I had something close to working for 'cp', but realized
another problem with this.

Here is the limit on file descriptors on my Fedora 42 system without
messing with configurations:

     $ ulimit -n
     1024

It is easy to hit this limit even if you only open file descriptors to
the parents of the file that you want to copy.

I'm considering a gnulib module with an implemented version of the
following:

   int
   open_deep (char const *filename, int flags, ...)
   {
     mode_t mode = 0;

     /* Insert code to use va_list to get optional value here.  */

     /* Optimize for the common case of a sane file name length.  */
     int result = open (filename, flags, mode);
     if (0 <= result || errno != ENAMETOOLONG)
       return result;

     /* Loop through the patch components using openat on each
        until we open FILENAME.  */
     return result;
   }

While thinking about that, I'm curious is there a reason why savewd and
mkancesdirs don't use openat + mkdirat instead of using chdir in a child
process? Do these functions just predate the *at interfaces, or is there
another reason that I am missing?

Collin