This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cp "skipping file ..., as it was replaced while being copied
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Tue, 09 Apr 2013 10:21:33 -0400
- 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> <20130409075058 dot GH10126 at calimero dot vinschen dot de>
On 4/9/2013 3:50 AM, Corinna Vinschen wrote:
On Apr 8 17:01, Charles Wilson wrote:
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?
It's a netapp Distributed File System. "K:" is mounted from a specific
(fairly deep) subdirectory, which -- IIUC -- is a specific volume
assigned to my project team, but it's under the umbrella of the overall
DFS manager.
It's actually mounted directly by my fstab.d/$user file as:
K:/ /k netapp binary,posix=0,exec 0 0
This is odd, because my "S:" drive is mounted to the top of the entire
DFS structure, in my /etc/fstab file:
S:/ /s netapp binary,posix=0 0 0
Stranger still, my "F:" drive is mounted to a direct child of the DFS
structure:
F:/ /f netapp binary,posix=0 0 0
So, summarizing:
==== Windows mount definitions: ====
S: = \\dfs.server\data
F: = \\dfs.server\data\Apps
K: = \\dfs.server\DATA\General\MyProject
(no, I don't know why the case difference)
==== cygwin fstab definitions: ====
S:/ /s netapp binary,posix=0 0 0
F:/ /f netapp binary,posix=0 0 0
K:/ /k netapp binary,posix=0,exec 0 0
==== cygwin mount -m report: ====
S: /s ntfs binary,posix=0 0 0
F: /f netapp binary,posix=0 0 0
K: /k cifs binary,exec,posix=0,user 0 0
(I don't have write permission in the F: area, so I can only test S: and K:)
===== S: =====
user@machine /s/Programs/public/user $ ls -l bob
-rw-rw-r--+ 1 user group 21 Apr 9 10:06 bob
user@machine /s/Programs/public/user $ getfacl bob
# file: bob
# owner: user
# group: group
user::rw-
group::rw-
group:root:rwx
mask:rwx
other:r--
user@machine /s/Programs/public/user $ cp bob fred
<success>
===== K: =====
user@machine /k/Users/user $ ls -l bob
-rw-rw-r--+ 1 user group 21 Apr 9 10:11 bob
user@machine /k/Users/user $ getfacl bob
# file: bob
# owner: user
# group: group
user::rw-
group::rw-
group:root:rwx
group:SYSTEM:rwx
mask:rwx
other:r--
user@machine /k/Users/user $ cp bob fred
cp: skipping file `bob', as it was replaced while being copied
Apart from that, try to mount the drive with the ihash mount option.
Does that help?
$ mount -m
...
K: /k cifs binary,exec,ihash,posix=0,user 0 0
user@machine /k/Users/user$ cp bob fred
<success>
Appears to help. Still confused as to why various subelements of our
netapp DFS hierarchy map to different fs types in the mount -m output,
even though the fstab entries for all of them say netapp...but I can
live with that.
--
Chuck
--
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