Pádraig Brady <[email protected]> writes: > On 16/10/2025 23:00, Collin Funk wrote: >> I was having a look at having 'cp' handle very long file names (see bug >> 70586 [1]): >> $ mkdir -p `python3 -c 'print("./" + "a/" * 32768)'` >> $ cp -r a b >> cp: cannot stat '[long file name snipped]': File name too long >> $ rm -rf a b >> The first step seemed to be changing this prototype from copy.h: >> bool copy (char const *src_name, char const *dst_name, >> int dst_dirfd, char const *dst_relname, >> int nonexistent_dst, const struct cp_options *options, >> bool *copy_into_self, bool *rename_succeeded) >> _GL_ATTRIBUTE_NONNULL ((1, 2, 4, 6, 7)); >> to also have a SRC_DIRFD and and SRC_RELNAME parameter. >> While changing all the invocations of this function, I noticed it >> was >> used to handle the --target-directory directory option. I couldn't find >> the thread where this was added to check if this was discussed, but was >> wondering if it makes sense to also add the --source-directory option to >> those programs. >> In the case of 'cp' this would allow you to copy files from paths >> that >> are too long for the 'open' or: >> open (AT_FDCWD, src_name, flags); >> WDYT? >> Collin >> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70586 >> > > One use of --target is to simplify use with xargs. > I.e.: find source/ | xargs cp --target=dest/
Ah, I see. Good to know. > Going the other way and supporting copying a file > to multiple destinations is much less required, > so we probably don't need a --source-directory option. Sure. Also, another part of the reason that 'cp' can't handle long filenames is the use of savedir from Gnulib, which uses opendir under the hood, which then calls open. I'll probably add a savedirat function to that file at some point. Collin
