#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 <anrdae...@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 (anrdae...@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
