cp "skipping file ..., as it was replaced while being copied
Fri Mar 29 20:26:00 GMT 2013
#1 I'm not transferring files
#2 The OS I'm connecting to only supports FTP & telnet.
#3 I saw lots of complaints and responses for requests for drive info;
but I never saw an explanation of why this checking is being done.
Here is my drive info:
Device Type : 7
Characteristics : 10
Volume Name : <172.16.40.128>
Serial Number : 71466
Max Filenamelength : 256
Filesystemname : <WebDrive>
Flags : f
FILE_CASE_SENSITIVE_SEARCH : TRUE
FILE_CASE_PRESERVED_NAMES : TRUE
FILE_UNICODE_ON_DISK : TRUE
FILE_PERSISTENT_ACLS : TRUE
FILE_FILE_COMPRESSION : FALSE
FILE_VOLUME_QUOTAS : FALSE
FILE_SUPPORTS_SPARSE_FILES : FALSE
FILE_VOLUME_IS_COMPRESSED : FALSE
FILE_SUPPORTS_OBJECT_IDS : FALSE
FILE_SUPPORTS_ENCRYPTION : FALSE
FILE_NAMED_STREAMS : FALSE
FILE_READ_ONLY_VOLUME : FALSE
FILE_SEQUENTIAL_WRITE_ONCE : FALSE
FILE_SUPPORTS_TRANSACTIONS : FALSE
On Fri, Mar 29, 2013 at 10:31 AM, Andrey Repin <email@example.com> wrote:
> Greetings, Bill Priest!
>> I've been using a program/device driver that maps an FTP site to a
>> windows drive (yes I know about the Windows 7 way to do almost the
>> same thing; but I could only get to the share using windows explorer
>> and not cygwin) and things work pretty well except when I try to do a
>> simple cp file1.txt file2.txt I get the following:
>> /usr/bin/cp: skipping file `file1.txt', as it was replaced while being copied
>> I found the "offending" code in copy.c and commented it out and the
>> resulting excutable then "works". I'm not sure why the inodes are the
>> same for both files. I've never seen this w/ samba or "normal"
>> network shares; I guess it is a bug in the driver implementation
>> (however, mv file1.txt file2.txt, cat file1.txt > file2.txt, and other
>> commands I have tried work w/o issue). I'm not sure what the code is
>> trying to protect against (once the open works shouldn't you be able
>> to trust the OS that the rest will work)??
>> I'm not reporting this as a bug as much as trying intellectual
>> curiosity of why the code is doing it.
> Search archives, this is not the first time this issue is brought to light.
> TL;DR: your bridge program does not behave as proper FS.
> That aside, why you are not using more efficient and secure means of file transfer?
>> diff -u copy.c~ copy.c
>> --- copy.c~ 2013-03-28 13:48:47.923995100 -0500
>> +++ copy.c 2013-03-29 08:49:03.795004400 -0500
>> @@ -835,6 +835,7 @@
>> /* Compare the source dev/ino from the open file to the incoming,
>> saved ones obtained via a previous call to stat. */
>> +#if 0
>> if (! SAME_INODE (*src_sb, src_open_sb))
>> error (0, 0,
>> @@ -843,7 +844,7 @@
>> return_val = false;
>> goto close_src_desc;
>> /* The semantics of the following open calls are mandated
>> by the specs for both cp and mv. */
>> if (! *new_dst)
>> Problem reports: http://cygwin.com/problems.html
>> FAQ: http://cygwin.com/faq/
>> Documentation: http://cygwin.com/docs.html
>> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Andrey Repin (firstname.lastname@example.org) 29.03.2013, <19:29>
> Sorry for my terrible english...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin