This is the mail archive of the
mailing list for the Cygwin project.
Re: cp "skipping file ..., as it was replaced while being copied
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 9 Apr 2013 09:50:58 +0200
- Subject: Re: cp "skipping file ..., as it was replaced while being copied
- References: <CAP_ScW1ARAqsKF8yADP4ZRzkF1COCo9GRWjX=-kFrwOsM-aCmQ at mail dot gmail dot com> <1846269758 dot 20130329193140 at mtu-net dot ru> <CAP_ScW1LoTkB7KobeM+xufvhP7tazUPh9evK-0WMCXR9_DhPKg at mail dot gmail dot com> <5155FB50 dot 1090709 at cygwin dot com> <51633042 dot 3090709 at cwilson dot fastmail dot fm>
- Reply-to: cygwin at cygwin dot com
On Apr 8 17:01, Charles Wilson wrote:
> On 3/29/2013 4:36 PM, Larry Hall (Cygwin) wrote:
> >On 3/29/2013 4:25 PM, Bill Priest wrote:
> >>#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.
> >I haven't looked at the code like you have but I believe this is to
> >avoid the case of the file being copied onto itself.
> FWIW, I am also seeing this problem, on a remote share (not "ftp")
> mounted to a drive letter, or via its UNC path. I've worked around
> the issue by using rsync to copy the file, rather than cp (rcp and
> scp also fail). I'm not sure what rsync does differently, but it
> user@machine /k/path $ cp bob fred
> cp: skipping file `bob', as it was replaced while being copied
cp checks the inode numbers before and after, and it seems the inode
numbers on this drive are not persistent.
> user@machine /k/path $ /usr/lib/csih/getVolInfo.exe /k
> Device Type : 7
> Characteristics : 10
> Volume Name : <programs10>
> Serial Number : 2684354574
> Max Filenamelength : 255
> Filesystemname : <NTFS>
> Flags : 4004e
> FILE_CASE_SENSITIVE_SEARCH : FALSE
> 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 : TRUE
> 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 : TRUE
> FILE_READ_ONLY_VOLUME : FALSE
> FILE_SEQUENTIAL_WRITE_ONCE : FALSE
> FILE_SUPPORTS_TRANSACTIONS : FALSE
> user@machine /k/path $ mount -m
> C: /c ntfs binary,posix=0 0 0
> F: /f netapp binary,posix=0 0 0
> H: /h netapp binary,posix=0,user 0 0
> K: /k cifs binary,exec,posix=0,user 0 0
Drive K: is not recognized. It's *some* drive, claiming to be NTFS, but
not being NTFS, and the rules to recognize Samba drive don't match either.
What kind of drive is that?
Apart from that, try to mount the drive with the ihash mount option.
Does that help?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple