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: List-Subscribe: List-Archive: List-Post: List-Help: , 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: <1846269758 DOT 20130329193140 AT mtu-net DOT ru> Date: Fri, 29 Mar 2013 15:25:55 -0500 Message-ID: Subject: Re: cp "skipping file ..., as it was replaced while being copied From: Bill Priest To: Andrey Repin Content-Type: text/plain; charset=ISO-8859-1 #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 : 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 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