1.7.1: cvs version built in is unstable
Roe, Kevin L.
roe2@llnl.gov
Wed Mar 17 21:41:00 GMT 2010
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-owner@cygwin.com [mailto:cygwin-owner@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-owner@cygwin.com [mailto:cygwin-owner@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
More information about the Cygwin
mailing list