cp "skipping file ..., as it was replaced while being copied

Bill Priest priestwilliaml@gmail.com
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:

/usr/lib/csih/getVolInfo.exe /cygdrive/q

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_SUPPORTS_REPARSE_POINTS: FALSE
 FILE_SUPPORTS_REMOTE_STORAGE: 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 <anrdaemon@freemail.ru> wrote:
> Greetings, Bill Priest!
>
>> All,
>>   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?
>
>> Bill
>
>> 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;
>>   }
>> -
>> +#endif
>>       /* 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
>
>
>
> --
> WBR,
> Andrey Repin (anrdaemon@freemail.ru) 29.03.2013, <19:29>
>
> Sorry for my terrible english...
>

--
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



More information about the Cygwin mailing list