X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=Ka
	TGFwDDWyUalG2kQKk3Qv1K0xYtWXw7AzNl1mhj/AMy0bapWdy0K2nblZjflO+01R
	jb6tuc5VYF5mn8Y7HKzV/Ax3k//6UMmMvo2XRyPE6DT3MJ9Vuxb/iy1ZoDVTQ2Hu
	4K+vlbeShJNfJrLqxIpi1zwIlEPV69L5g/fr7EVcg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=yTD7LeUU
	sfv8uVMpPWzV+gIsdQQ=; b=dCVZdVdFBKgHLmMbL/10l8VaipvMLAY9e6zwAdZC
	P5YDDLkKB6mhf2uwvOpzmKWqzVs7+KSqcL8AjXL/Ie3xEhlvaW1KPVkzh7pfrN45
	gRjGxbSd+AlQGl4BlfDaH+UdxOnHab6cRK+7K5E49PWunR5xMBDXW+HrtukbAxyw
	9Dc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FREEMAIL_REPLY,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1
MIME-Version:	1.0
X-Received:	by 10.50.212.3 with SMTP id ng3mr22223igc.43.1364588755246; Fri, 29 Mar 2013 13:25:55 -0700 (PDT)
In-Reply-To:	<1846269758.20130329193140@mtu-net.ru>
References:	<CAP_ScW1ARAqsKF8yADP4ZRzkF1COCo9GRWjX=-kFrwOsM-aCmQ AT mail DOT gmail DOT com> <1846269758 DOT 20130329193140 AT mtu-net DOT ru>
Date:	Fri, 29 Mar 2013 15:25:55 -0500
Message-ID:	<CAP_ScW1LoTkB7KobeM+xufvhP7tazUPh9evK-0WMCXR9_DhPKg@mail.gmail.com>
Subject:	Re: cp "skipping file ..., as it was replaced while being copied
From:	Bill Priest <priestwilliaml AT gmail DOT com>
To:	Andrey Repin <cygwin AT cygwin DOT com>

#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 AT freemail DOT 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 AT freemail DOT 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

- Raw text -