Re: Fun with cp -R error when both foo and foo.exe exist
- Date: Tue, 9 Oct 2018 07:02:59 -0500
- From: Eric Blake <eblake@xxxxxxxxxx>
- Subject: Re: Fun with cp -R error when both foo and foo.exe exist
On 10/9/18 1:22 AM, Marco Atzeri wrote:
Am 08.10.2018 um 23:24 schrieb Dan Kegel:
A nice workaround might be for the cygwin version of cp could arrange
to wait to create .exe files until after any potential non-suffixed
file has been processed... not sure how easy that would be.
Apologies if this has already been discussed.
it is not cp handling the magic, but the cygwin dll.
Mostly the cygwin dll, but cp itself DOES have some cygwin-specific
downstream patches to try and behave smarter. At any rate, POSIX
requires cp to handle command line arguments in the order given, but
does not require recursion to copy in any specific order for files
within a directory. But the order that makes the most sense is the
order that readdir() returns things, because any other order requires
sorting the files (and thus the memory to track the files) and a longer
window for races to occur with anything else changing directory contents
in parallel. Perhaps you could even argue that readdir() should visit
'foo' and 'foo.exe' in a particular order, no matter whether the native
ordering would display them in the opposite order. But in general,
whether someone patches the cygwin dll or cp, it seems like some rather
hairy code for what is normally a rare corner case, so it probably won't
happen unless someone actually contributes a patch.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple