This appears to be related to another problem I am encountering. I have described it in the thread "cp: skipping file 'file.txt', as it was replaced while being copied"
The same drive that has the CVS issue has the "cp" issue and the other drive has neither issue. -Kevin -----Original Message----- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Wednesday, March 17, 2010 2:36 PM To: Cygwin Tech List Subject: RE: 1.7.1: cvs version built in is unstable I think you're onto something. It works fine on the same system, but on a different drive (unfortunately that drive is going away) It is a "mac server, samba shares" Here are the results of the command "/usr/lib/csih/getVolInfo /cygdrive/$drive" Device Type : 7 Characteristics : 10 Max Filenamelength : 255 Filesystemname : <NTFS> Flags : 4002b FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK : FALSE FILE_PERSISTENT_ACLS : TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE 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 : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE -----Original Message----- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Wednesday, March 17, 2010 2:33 PM To: Cygwin Tech List Subject: RE: 1.7.1: cvs version built in is unstable It is a "netapp, nfs" Here are the results of the command "/usr/lib/csih/getVolInfo /cygdrive/$drive" Device Type : 7 Characteristics : 10 Max Filenamelength : 255 Filesystemname : <NTFS> Flags : 4004f 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 : 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 Andy wrote: > >Corinna Vinschen: >>>what would cause >>> >>> open(".new.p_change.pl", O_WRONLY | O_CREAT | O_TRUNC, 0777) >>> >>> to fail with errno set to ENOENT. >> >>Just as in Linux: >> >>ENOENT O_CREAT is not set and the named file does not exist. Or, a >> directory component in pathname does not exist or is a dangling >> symbolic link. > >The way I understand this, the open() call shouldn't fail with ENOENT >given those arguments, because O_CREAT is set and there is no >directory component in the pathname. > >What type of file system is your checkout on? > >Andy
