Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 23 13:12, Corinna Vinschen wrote: I didn't like this solution at all. I just applied another patch which handles that differently. Instead of stripping the leading spaces and trailing dots and spaces, they now get converted the same way as described in http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars So the offending dots and spaces are converted into the UNICODE private use area instead, and transparently converted back to dots and spaces when accessing them via Cygwin. This allows to keep the filenames unchanged from the user's point of view. The file abc... is *still* the file abc... even on the broken filesystems. Again I tested this change on NTFS with a little tweak to the code. If you NetApp and NWFS users please test the next developer's snapshot (the next one after 2010-04-22), I would be most grateful. Anybody? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
Corinna, I **really** want to try this snapshot, but unfortunately my sys-admins have locked down access right now. There is no forecast on when I'll get access. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, April 26, 2010 8:15 AM To: cygwin@cygwin.com Subject: Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable) On Apr 23 13:12, Corinna Vinschen wrote: I didn't like this solution at all. I just applied another patch which handles that differently. Instead of stripping the leading spaces and trailing dots and spaces, they now get converted the same way as described in http://*cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames- specialchars So the offending dots and spaces are converted into the UNICODE private use area instead, and transparently converted back to dots and spaces when accessing them via Cygwin. This allows to keep the filenames unchanged from the user's point of view. The file abc... is *still* the file abc... even on the broken filesystems. Again I tested this change on NTFS with a little tweak to the code. If you NetApp and NWFS users please test the next developer's snapshot (the next one after 2010-04-22), I would be most grateful. Anybody? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 22 19:51, Corinna Vinschen wrote: On Apr 22 14:12, Corinna Vinschen wrote: Thank you. Oh well. When trying to open the file to check for its existance, the NT status code is STATUS_OBJECT_NAME_NOT_FOUND which is equivalent to the POSIX errno ENOENT, No such file or directory. Only afterwards, when trying to create the file, the status code is STATUS_OBJECT_NAME_INVALID. Too late for Cygwin. I've just applied a patch which is supposed to fix this problem. The core component which evaluates a file and performs basic checks now handles the case STATUS_OBJECT_NAME_NOT_FOUND specially. It checks if the filename has leading spaces and/or trailing dots and spaces. If so, it checks the filesystem. If it's one of the known FSes with broken (aka DOS-only) path handling, it removes the offending leading spaces and trailing dots and spaces and tries again. So this: $ touch abc... will create the file abc... for instance on NTFS or FAT, but it will create the file abc on NetApp, NWFS and other filesystems recognized as CIFS (but not Samba). This behaviour is equivalent to the behaviour in native Win32 applications and in Cygwin 1.5. While I tested the patch, I had to fake a detail to make it work on NTFS. I have no access to one of the broken filesystems myself, so a bit of testing under real-life conditions would be quite helpful. So I'd like to urge all users who could reproduce the aforementioned problems to test the *next* Cygwin DLL from the Cygwin Developer Snapshots URL http://cygwin.com/snapshots/ and report back if it works or if it doesn't. *If* it doesn't work, please report the FS and describe the scenario. Oh, hey, the cvs problem which started this thread would be quite a nice test. The patch is available in the latest snapshot from 2010-04-22. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 23 10:45, Corinna Vinschen wrote: On Apr 22 19:51, Corinna Vinschen wrote: On Apr 22 14:12, Corinna Vinschen wrote: Thank you. Oh well. When trying to open the file to check for its existance, the NT status code is STATUS_OBJECT_NAME_NOT_FOUND which is equivalent to the POSIX errno ENOENT, No such file or directory. Only afterwards, when trying to create the file, the status code is STATUS_OBJECT_NAME_INVALID. Too late for Cygwin. I've just applied a patch which is supposed to fix this problem. The core component which evaluates a file and performs basic checks now handles the case STATUS_OBJECT_NAME_NOT_FOUND specially. It checks if the filename has leading spaces and/or trailing dots and spaces. If so, it checks the filesystem. If it's one of the known FSes with broken (aka DOS-only) path handling, it removes the offending leading spaces and trailing dots and spaces and tries again. So this: $ touch abc... will create the file abc... for instance on NTFS or FAT, but it will create the file abc on NetApp, NWFS and other filesystems recognized as CIFS (but not Samba). I didn't like this solution at all. I just applied another patch which handles that differently. Instead of stripping the leading spaces and trailing dots and spaces, they now get converted the same way as described in http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars So the offending dots and spaces are converted into the UNICODE private use area instead, and transparently converted back to dots and spaces when accessing them via Cygwin. This allows to keep the filenames unchanged from the user's point of view. The file abc... is *still* the file abc... even on the broken filesystems. Again I tested this change on NTFS with a little tweak to the code. If you NetApp and NWFS users please test the next developer's snapshot (the next one after 2010-04-22), I would be most grateful. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 7 19:27, Corinna Vinschen wrote: On Apr 7 19:06, Corinna Vinschen wrote: On Apr 7 09:06, Roe, Kevin L. wrote: Corinna, My problem system is the netapp you previously in this thread helped me with (the issue with the cp command). It is not a Samba system. Ok, back to square one. I add the problem to my TODO list. We need a way to allow only DOS filenames on crippled filesystems. Since I don't have such a filesystem myself, I'll need to come back to you for testing at one point. Btw. Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. For testing, try to create *in Cygwin* a file called foo. and a file foo . If it works, and if a following `ls' and `rm' on the file works as well, everything's fine. If some error occurs, especially No such file or directory, then that filesystem probably requires special handling just like netapp. Here's another question to those who can reproduce the problem. What I need is an strace from one netapp and and one nwfs filesystem when trying to create a file with trailing dots and spaces: for the following scenarios: $ strace -o lame_fs.trace touch 'foo.' 'foo ' This will help to create a workaround for those filesystems. I only need straces for the *not* working cases. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: [bulk] - Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 22 13:44, DEWI - N. Zacharias wrote: Hi Corinna, please have a look at the attachment. Thank you. Oh well. When trying to open the file to check for its existance, the NT status code is STATUS_OBJECT_NAME_NOT_FOUND which is equivalent to the POSIX errno ENOENT, No such file or directory. Only afterwards, when trying to create the file, the status code is STATUS_OBJECT_NAME_INVALID. Too late for Cygwin. That's tragic. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 22 14:12, Corinna Vinschen wrote: On Apr 22 13:44, DEWI - N. Zacharias wrote: Hi Corinna, please have a look at the attachment. Thank you. Oh well. When trying to open the file to check for its existance, the NT status code is STATUS_OBJECT_NAME_NOT_FOUND which is equivalent to the POSIX errno ENOENT, No such file or directory. Only afterwards, when trying to create the file, the status code is STATUS_OBJECT_NAME_INVALID. Too late for Cygwin. That's tragic. I've just applied a patch which is supposed to fix this problem. The core component which evaluates a file and performs basic checks now handles the case STATUS_OBJECT_NAME_NOT_FOUND specially. It checks if the filename has leading spaces and/or trailing dots and spaces. If so, it checks the filesystem. If it's one of the known FSes with broken (aka DOS-only) path handling, it removes the offending leading spaces and trailing dots and spaces and tries again. So this: $ touch abc... will create the file abc... for instance on NTFS or FAT, but it will create the file abc on NetApp, NWFS and other filesystems recognized as CIFS (but not Samba). This behaviour is equivalent to the behaviour in native Win32 applications and in Cygwin 1.5. While I tested the patch, I had to fake a detail to make it work on NTFS. I have no access to one of the broken filesystems myself, so a bit of testing under real-life conditions would be quite helpful. So I'd like to urge all users who could reproduce the aforementioned problems to test the *next* Cygwin DLL from the Cygwin Developer Snapshots URL http://cygwin.com/snapshots/ and report back if it works or if it doesn't. *If* it doesn't work, please report the FS and describe the scenario. Oh, hey, the cvs problem which started this thread would be quite a nice test. Thanks in advance, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: [bulk] - PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 8 07:41, DEWI - N. Zacharias wrote: Hi , Von: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Gesendet: Mittwoch, 7. April 2010 19:27 An: cygwin@cygwin.com Betreff: [bulk] - PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable) [...] Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. on a Novell Network drive $ echo bal foo. bash: foo.: No such file or directory $ $ echo bal foo $ $ ls -al foo -rw-r--r-- 1 n-zacharias Kein 5 2010-04-08 07:37 foo Thanks, so we have to add NWFS to the list as well. Oh well. These filename-crippled filesystems are really a chicken/egg problem, codewise. On one hand Cygwin can't open the files and gets an ENOENT kind of error from NT, on the other hand Cygwin needs the open file handle to get information about the underlying filesystem. I'm not sure yet how to solve this problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: 1.7.1: cvs version built in is unstable
On Apr 6 21:06, Charles Wilson wrote: On 4/6/2010 1:33 PM, Roe, Kevin L. wrote: Is it possible to change the setting of POSIX_NO_TRUNC? No. That symbol (accurately) describes the underlying behavior of the C runtime library (in this case, the new cygwin1.dll) and is defined in /usr/include/sys/features.h. You really don't want to start lying about the behavior of your C library; that way lies madness. The real solution lies in Cygwin, I fear. We probably have to add a tweak to the pathname handling which reverts to good old Win32 compatible filenames (no leading spaces, no trailing dots and spaces) when the target filesystem is Samba. I look into it, but maybe not for 1.7.4. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: 1.7.1: cvs version built in is unstable
On Apr 7 10:34, Corinna Vinschen wrote: On Apr 6 21:06, Charles Wilson wrote: On 4/6/2010 1:33 PM, Roe, Kevin L. wrote: Is it possible to change the setting of POSIX_NO_TRUNC? No. That symbol (accurately) describes the underlying behavior of the C runtime library (in this case, the new cygwin1.dll) and is defined in /usr/include/sys/features.h. You really don't want to start lying about the behavior of your C library; that way lies madness. The real solution lies in Cygwin, I fear. We probably have to add a tweak to the pathname handling which reverts to good old Win32 compatible filenames (no leading spaces, no trailing dots and spaces) when the target filesystem is Samba. I look into it, but maybe not for 1.7.4. I'm sorry, but I don't see a problem with these filenames on Samba: $ touch a.b. $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 AB2F49~0 $ ls -l a.b. -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 a.b. $ rm a.b. $ touch abc $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 AZIJUG~1 $ ls -l abc -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 abc $ rm abc I also tested cvs, and it didn't complain about filenames with a dot as the 9th char. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
Corinna, My problem system is the netapp you previously in this thread helped me with (the issue with the cp command). It is not a Samba system. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, April 07, 2010 1:54 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Apr 7 10:34, Corinna Vinschen wrote: On Apr 6 21:06, Charles Wilson wrote: On 4/6/2010 1:33 PM, Roe, Kevin L. wrote: Is it possible to change the setting of POSIX_NO_TRUNC? No. That symbol (accurately) describes the underlying behavior of the C runtime library (in this case, the new cygwin1.dll) and is defined in /usr/include/sys/features.h. You really don't want to start lying about the behavior of your C library; that way lies madness. The real solution lies in Cygwin, I fear. We probably have to add a tweak to the pathname handling which reverts to good old Win32 compatible filenames (no leading spaces, no trailing dots and spaces) when the target filesystem is Samba. I look into it, but maybe not for 1.7.4. I'm sorry, but I don't see a problem with these filenames on Samba: $ touch a.b. $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 AB2F49~0 $ ls -l a.b. -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 a.b. $ rm a.b. $ touch abc $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 AZIJUG~1 $ ls -l abc -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 abc $ rm abc I also tested cvs, and it didn't complain about filenames with a dot as the 9th char. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
On Apr 7 09:06, Roe, Kevin L. wrote: Corinna, My problem system is the netapp you previously in this thread helped me with (the issue with the cp command). It is not a Samba system. Ok, back to square one. I add the problem to my TODO list. We need a way to allow only DOS filenames on crippled filesystems. Since I don't have such a filesystem myself, I'll need to come back to you for testing at one point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
On Apr 7 19:06, Corinna Vinschen wrote: On Apr 7 09:06, Roe, Kevin L. wrote: Corinna, My problem system is the netapp you previously in this thread helped me with (the issue with the cp command). It is not a Samba system. Ok, back to square one. I add the problem to my TODO list. We need a way to allow only DOS filenames on crippled filesystems. Since I don't have such a filesystem myself, I'll need to come back to you for testing at one point. Btw. Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. For testing, try to create *in Cygwin* a file called foo. and a file foo . If it works, and if a following `ls' and `rm' on the file works as well, everything's fine. If some error occurs, especially No such file or directory, then that filesystem probably requires special handling just like netapp. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
I've tested on 2 Netapp shares, 1 that uses UNIX permissions and the other uses NTFS permissions. Both failed for both cases. Dave -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, April 07, 2010 1:27 PM To: cygwin@cygwin.com Subject: PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable) On Apr 7 19:06, Corinna Vinschen wrote: On Apr 7 09:06, Roe, Kevin L. wrote: Corinna, My problem system is the netapp you previously in this thread helped me with (the issue with the cp command). It is not a Samba system. Ok, back to square one. I add the problem to my TODO list. We need a way to allow only DOS filenames on crippled filesystems. Since I don't have such a filesystem myself, I'll need to come back to you for testing at one point. Btw. Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. For testing, try to create *in Cygwin* a file called foo. and a file foo . If it works, and if a following `ls' and `rm' on the file works as well, everything's fine. If some error occurs, especially No such file or directory, then that filesystem probably requires special handling just like netapp. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
RE: 1.7.1: cvs version built in is unstable
I tried the touch command and here are the results: Drive behaving nicely: /cygdrive/h 510 $ touch foo. Drive behaving badly: /cygdrive/f 511 $ touch foo. touch: cannot touch `foo.`: No such file or directory This looks like the culprit. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, April 07, 2010 1:54 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Apr 7 10:34, Corinna Vinschen wrote: On Apr 6 21:06, Charles Wilson wrote: On 4/6/2010 1:33 PM, Roe, Kevin L. wrote: Is it possible to change the setting of POSIX_NO_TRUNC? No. That symbol (accurately) describes the underlying behavior of the C runtime library (in this case, the new cygwin1.dll) and is defined in /usr/include/sys/features.h. You really don't want to start lying about the behavior of your C library; that way lies madness. The real solution lies in Cygwin, I fear. We probably have to add a tweak to the pathname handling which reverts to good old Win32 compatible filenames (no leading spaces, no trailing dots and spaces) when the target filesystem is Samba. I look into it, but maybe not for 1.7.4. I'm sorry, but I don't see a problem with these filenames on Samba: $ touch a.b. $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 AB2F49~0 $ ls -l a.b. -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:36 a.b. $ rm a.b. $ touch abc $ ls -l [...] -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 AZIJUG~1 $ ls -l abc -rw-r--r-- 1 corinna vinschen 0 2010-04-07 10:40 abc $ rm abc I also tested cvs, and it didn't complain about filenames with a dot as the 9th char. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
AW: [bulk] - PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable)
Hi , Von: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Gesendet: Mittwoch, 7. April 2010 19:27 An: cygwin@cygwin.com Betreff: [bulk] - PLEASE TEST YOUR FS (was Re: 1.7.1: cvs version built in is unstable) [...] Can anybody reproduce this problem with trailing dots and spaces in filenames on other filesytems than netapp? It would be quite helpful to get feedback from people using filesystems which are recognized by Cygwin as nwfs, unixfs, mvfs, or cifs. on a Novell Network drive $ echo bal foo. bash: foo.: No such file or directory $ $ echo bal foo $ $ ls -al foo -rw-r--r-- 1 n-zacharias Kein 5 2010-04-08 07:37 foo On NTFS $ echo bal foo. $ echo bal foo $ ls -al foo* -rw-r--r--+ 1 n-zacharias Kein 5 2010-04-08 07:41 foo -rw-r--r--+ 1 n-zacharias Kein 5 2010-04-08 07:41 foo. Hope this helps. Have a nice day Norbert For testing, try to create *in Cygwin* a file called foo. and a file foo . If it works, and if a following `ls' and `rm' on the file works as well, everything's fine. If some error occurs, especially No such file or directory, then that filesystem probably requires special handling just like netapp. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this email. -- 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
RE: 1.7.1: cvs version built in is unstable
I'm seeing stuff like this too, and it is unrelated to ssh. The problem is that cvs download temp files into temp files named .new.%9 and the 9th character of that name is a dot. It appears that most windows file systems don't allow trailing dots, apparently because of 8.3 filename legacy logic. It appears that cygwin 1.5 munged off the dot, or defined _POSIX_NO_TRUNC. And now with 1.7 that has changed. - doug -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Tuesday, March 30, 2010 7:37 PM To: cygwin@cygwin.com Subject: RE: 1.7.1: cvs version built in is unstable So I ran the cvs -t update command on the file in question. Doesn't tell me anything, but here is the output. - main: Session ID is NrLenMDBO35CD1tu - main loop with CVSROOT=/usr/gapps/AEAG/cvs_modules - open_connection_to_server (:ext:hera:/usr/gapps/AEAG/cvs_modules) - Starting server: ssh hera cvs server Password: S- Reader_Lock(/usr/gapps/AEAG/cvs_modules/Utilities) cvs update: warning: p_change.pl was lost S- RCS_Checkout (usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, 1.5, , , (function)) S- server_register(p_change.pl, 1.5, , , , , ) S- Register(p_change.pl, 1.5, , , ) S- fopen(/usr/gapps/AEAG/cvs_modules/CVSROOT/history,a) cvs update: cannot write ./p_change.pl: No such file of directory S- Lock_Cleanup() S- rename(CVS/Entries.Backup,CVS/Entries) - close_connection_to_server () - Lock_Cleanup() I also tried using the -vvv option on ssh, but got the following error when I set CVS_RSH to that: cvs [update aborted]: cannot exec ssh -vvv: No such file or directory -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Larry Hall (Cygwin) Sent: Tuesday, March 30, 2010 4:12 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On 3/30/2010 6:58 PM, Roe, Kevin L. wrote: snip New information: I have confirmed that the current CVS (1.12.13) in cygwin is the same as in cygwin 1.5.25 The ssh is different though, old = OpenSSH_5.1p1 new = OpenSSH_5.3p1 snip I'd like to get the native CVS working in cygwin. It is the cleanest solution. Any ideas on where I can go from here? I suggest trying to reproduce CVS's usage of ssh to see if you can narrow down where the problem lies. -- Larry Hall http://*www.*rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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 -- 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
RE: 1.7.1: cvs version built in is unstable
Is it possible to change the setting of POSIX_NO_TRUNC? -Kevin -Original Message- From: seay_doug...@emc.com [mailto:seay_doug...@emc.com] Sent: Tuesday, April 06, 2010 6:47 AM To: Roe, Kevin L.; cygwin@cygwin.com Subject: RE: 1.7.1: cvs version built in is unstable I'm seeing stuff like this too, and it is unrelated to ssh. The problem is that cvs download temp files into temp files named .new.%9 and the 9th character of that name is a dot. It appears that most windows file systems don't allow trailing dots, apparently because of 8.3 filename legacy logic. It appears that cygwin 1.5 munged off the dot, or defined _POSIX_NO_TRUNC. And now with 1.7 that has changed. - doug -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Tuesday, March 30, 2010 7:37 PM To: cygwin@cygwin.com Subject: RE: 1.7.1: cvs version built in is unstable So I ran the cvs -t update command on the file in question. Doesn't tell me anything, but here is the output. - main: Session ID is NrLenMDBO35CD1tu - main loop with CVSROOT=/usr/gapps/AEAG/cvs_modules - open_connection_to_server (:ext:hera:/usr/gapps/AEAG/cvs_modules) - Starting server: ssh hera cvs server Password: S- Reader_Lock(/usr/gapps/AEAG/cvs_modules/Utilities) cvs update: warning: p_change.pl was lost S- RCS_Checkout (usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, 1.5, , , (function)) S- server_register(p_change.pl, 1.5, , , , , ) S- Register(p_change.pl, 1.5, , , ) S- fopen(/usr/gapps/AEAG/cvs_modules/CVSROOT/history,a) cvs update: cannot write ./p_change.pl: No such file of directory S- Lock_Cleanup() S- rename(CVS/Entries.Backup,CVS/Entries) - close_connection_to_server () - Lock_Cleanup() I also tried using the -vvv option on ssh, but got the following error when I set CVS_RSH to that: cvs [update aborted]: cannot exec ssh -vvv: No such file or directory -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Larry Hall (Cygwin) Sent: Tuesday, March 30, 2010 4:12 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On 3/30/2010 6:58 PM, Roe, Kevin L. wrote: snip New information: I have confirmed that the current CVS (1.12.13) in cygwin is the same as in cygwin 1.5.25 The ssh is different though, old = OpenSSH_5.1p1 new = OpenSSH_5.3p1 snip I'd like to get the native CVS working in cygwin. It is the cleanest solution. Any ideas on where I can go from here? I suggest trying to reproduce CVS's usage of ssh to see if you can narrow down where the problem lies. -- Larry Hall http://**www.**rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
On 4/6/2010 1:33 PM, Roe, Kevin L. wrote: Is it possible to change the setting of POSIX_NO_TRUNC? No. That symbol (accurately) describes the underlying behavior of the C runtime library (in this case, the new cygwin1.dll) and is defined in /usr/include/sys/features.h. You really don't want to start lying about the behavior of your C library; that way lies madness. -- 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
RE: 1.7.1: cvs version built in is unstable
The issue with the cp command has been resolved. My netapp drive was not being correctly recognized as such by cygwin. It was interpreted as a cifs. This has been corrected in 1.7.3 However, the original point of this thread was a problem with CVS. This is not resolved. To recap: The situation: I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. I then try to update the same module and get the same error on the same files. I check it out again and get exactly the same response on exactly the same files. I have checked the permissions on the files in the repository. I have removed some watches that were on some of the files. Bottom line: I have a very repeatable problem with no evidence of a cause I've found. New information: I have confirmed that the current CVS (1.12.13) in cygwin is the same as in cygwin 1.5.25 The ssh is different though, old = OpenSSH_5.1p1 new = OpenSSH_5.3p1 Also, By setting: CVS_RSH='C:\Program Files\TortoiseCVS\Tortoiseplink.exe' alias cvs='/cygdrive/c/Program\ File\ \(x86\)/CVSNT/cvs.exe' I can get CVS to work. This is a hack and it works because I'm abandoning the built-in CVS. Further, the only cvseditor I can get to work is the default Notepad I'd like to get the native CVS working in cygwin. It is the cleanest solution. Any ideas on where I can go from here? -Kevin -- 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
Re: 1.7.1: cvs version built in is unstable
On 3/30/2010 6:58 PM, Roe, Kevin L. wrote: snip New information: I have confirmed that the current CVS (1.12.13) in cygwin is the same as in cygwin 1.5.25 The ssh is different though, old = OpenSSH_5.1p1 new = OpenSSH_5.3p1 snip I'd like to get the native CVS working in cygwin. It is the cleanest solution. Any ideas on where I can go from here? I suggest trying to reproduce CVS's usage of ssh to see if you can narrow down where the problem lies. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
RE: 1.7.1: cvs version built in is unstable
So I ran the cvs -t update command on the file in question. Doesn't tell me anything, but here is the output. - main: Session ID is NrLenMDBO35CD1tu - main loop with CVSROOT=/usr/gapps/AEAG/cvs_modules - open_connection_to_server (:ext:hera:/usr/gapps/AEAG/cvs_modules) - Starting server: ssh hera cvs server Password: S- Reader_Lock(/usr/gapps/AEAG/cvs_modules/Utilities) cvs update: warning: p_change.pl was lost S- RCS_Checkout (usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, 1.5, , , (function)) S- server_register(p_change.pl, 1.5, , , , , ) S- Register(p_change.pl, 1.5, , , ) S- fopen(/usr/gapps/AEAG/cvs_modules/CVSROOT/history,a) cvs update: cannot write ./p_change.pl: No such file of directory S- Lock_Cleanup() S- rename(CVS/Entries.Backup,CVS/Entries) - close_connection_to_server () - Lock_Cleanup() I also tried using the -vvv option on ssh, but got the following error when I set CVS_RSH to that: cvs [update aborted]: cannot exec ssh -vvv: No such file or directory -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Larry Hall (Cygwin) Sent: Tuesday, March 30, 2010 4:12 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On 3/30/2010 6:58 PM, Roe, Kevin L. wrote: snip New information: I have confirmed that the current CVS (1.12.13) in cygwin is the same as in cygwin 1.5.25 The ssh is different though, old = OpenSSH_5.1p1 new = OpenSSH_5.3p1 snip I'd like to get the native CVS working in cygwin. It is the cleanest solution. Any ideas on where I can go from here? I suggest trying to reproduce CVS's usage of ssh to see if you can narrow down where the problem lies. -- Larry Hall http://*www.*rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: 1.7.1: cvs version built in is unstable
On Mar 22 12:29, Corinna Vinschen wrote: On Mar 17 14:33, Roe, Kevin L. wrote: 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 What does `mount' tell you? Does it recognize the drive as netapp or does it recognize it as cifs? I assume the latter. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. I take it the problem has gone away. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
No, it hasn't. But I reached the end of what I could do with my knowledge level. I am currently trying to get my IT department to continue where I left off. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, March 29, 2010 4:44 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Mar 22 12:29, Corinna Vinschen wrote: On Mar 17 14:33, Roe, Kevin L. wrote: 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 What does `mount' tell you? Does it recognize the drive as netapp or does it recognize it as cifs? I assume the latter. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. I take it the problem has gone away. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
On Mar 29 09:07, Roe, Kevin L. wrote: No, it hasn't. But I reached the end of what I could do with my knowledge level. I am currently trying to get my IT department to continue where I left off. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. Then, what about this? I offered a potential solution if you only would install a test DLL. I won't apply my change to the official release without testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
Sorry, I missed your first e-mail and didn't notice the quote in the second one. From my side, the window has closed where I can install things myself. However, if you can send me the PM I'll push my IT to get it installed for evaluation. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, March 29, 2010 9:13 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Mar 29 09:07, Roe, Kevin L. wrote: No, it hasn't. But I reached the end of what I could do with my knowledge level. I am currently trying to get my IT department to continue where I left off. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. Then, what about this? I offered a potential solution if you only would install a test DLL. I won't apply my change to the official release without testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
RE: 1.7.1: cvs version built in is unstable
Corinna, mount gives the following with regard to a good drive G and a bad G G: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) H: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) So, in other words, not much really. There is a little bit of new info though. The disk in question has been set up to recognize Windows, Mac (Linux), and Linux. I am suspicious that that is causing problems for the Cygwin environment which is basically Linux but passes through Windows. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, March 29, 2010 4:44 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Mar 22 12:29, Corinna Vinschen wrote: On Mar 17 14:33, Roe, Kevin L. wrote: 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 What does `mount' tell you? Does it recognize the drive as netapp or does it recognize it as cifs? I assume the latter. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. I take it the problem has gone away. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
RE: 1.7.1: cvs version built in is unstable
Corinna, I just learned that the network folks here made a decision to go with cifs. That really surprised me because I thought what you were pointing me towards was that Cygwin was not correctly recognizing the drive. But it also makes sense due to what they have told me about how they set things up to be accessible from any type of machine. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Monday, March 29, 2010 9:22 AM To: cygwin@cygwin.com Subject: RE: 1.7.1: cvs version built in is unstable Corinna, mount gives the following with regard to a good drive G and a bad G G: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) H: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) So, in other words, not much really. There is a little bit of new info though. The disk in question has been set up to recognize Windows, Mac (Linux), and Linux. I am suspicious that that is causing problems for the Cygwin environment which is basically Linux but passes through Windows. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Monday, March 29, 2010 4:44 AM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Mar 22 12:29, Corinna Vinschen wrote: On Mar 17 14:33, Roe, Kevin L. wrote: 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 What does `mount' tell you? Does it recognize the drive as netapp or does it recognize it as cifs? I assume the latter. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. I take it the problem has gone away. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
On Mar 17 14:33, Roe, Kevin L. wrote: 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 What does `mount' tell you? Does it recognize the drive as netapp or does it recognize it as cifs? I assume the latter. If you're ok with testing a DLL, I'd send you a PM with a web site where you can download a Cygwin test DLL. I'd need feedback ASAP, otherwise the change will not be in 1.7.2. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
I suspect you are correct. I checked my older install of cygwin on another machine and found that it also has 1.12.13 I don't have problems with this copy and it is part of a cygwin install that has the same dll as the previous installation of cygwin on my other machine. I am pursuing this with the CVS folks, but they are not very responsive (as I would expect). -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Charles Wilson Sent: Tuesday, March 16, 2010 5:41 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On 3/16/2010 4:35 PM, Roe, Kevin L. wrote: The built in version of CVS is the unstable feature release version 1.12.13 I am having problems with CVS that I never had before I upgraded cygwin to 1.7.1. [snip] Has anybody seen this before? No. How do I downgrade CVS within cygwin down to the stable release 1.11.23 ? Use setup.exe. In the package chooser, go to the 'Up To Date' page. Find cvs. Click on the word 'keep' until it cycle around to the prev: version, 1.11.22-1 (we've never had a cygwin port of '1.11.23'). While I'm not ruling out a problem with cygwin's current cvs package, I tend to doubt it is the true culprit here. I'd be interested in hearing back (on this list) if cygwin-1.7.1 + cvs-1.11.22 actually fixes your problem; I rather doubt it will. -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
Here is what the CVS folks said in response to my e-mail to them. My original message is after their response. -Original Message- From: Larry Jones [mailto:lawrence.jo...@siemens.com] Sent: Wednesday, March 17, 2010 11:31 AM To: Roe, Kevin L. Cc: info-...@nongnu.org Subject: Re: No such file Roe, Kevin L. writes: S- RCS_checkout (/usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, 1.8, , , (function)) cvs checkout: cannot write Utilities/p_change.pl: No such file or directory H, that looks like some kind of a bug/incompatibility in cygwin. You need to ask the cygwin folks what would cause open(.new.p_change.pl, O_WRONLY | O_CREAT | O_TRUNC, 0777) to fail with errno set to ENOENT. -- Larry Jones I wonder if you can refuse to inherit the world. -- Calvin Here is the trace for a checkout. I've removed most of the file and left just two similarly named files. One failed and one succeeded. S- RCS_checkout (/usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, S- 1.8, , , (function)) cvs checkout: cannot write Utilities/p_change.pl: No such file or directory S- server_register(p_change.pl, 1.8, , , , , ) Register(p_change.pl, S- 1.8, , , ) S- RCS_checkout (/usr/gapps/AEAG/cvs_modules/Utilities/p_check.pl,v, S- 1.2, , , (function)) U Utilities/p_check.pl - rename(.new.p_check.pl,p_check.pl) - Register(p_check.pl, 1.2, Tue Jan 12 00:23:42 2010, , ) - rename(CVS/Entries.Backup,CVS/Entries) - unlink_file(CVS/Entries.Log) S- server_register(p_check.pl, 1.2, , , , , ) Register(p_check.pl, 1.2, S- , , ) -Kevin -Original Message- From: Larry Jones [mailto:lawrence.jo...@siemens.com] Sent: Tuesday, March 16, 2010 1:57 PM To: Roe, Kevin L. Cc: info-...@nongnu.org Subject: Re: No such file Roe, Kevin L. writes: The situation: I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. I then try to update the same module and get the same error on the same files. I check it out again and get exactly the same response on exactly the same files. Please run the update again with the -t global option to get a trace and post it. My guess is that the affected files have funky names that are confusing cygwin and/or Windows. -- Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin I'm going to try to add more information in the effort to get a response. My system setup: 64 bit XP Dual quad-core Cygwin 1.7.1 The situation: I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. I then try to update the same module and get the same error on the same files. I check it out again and get exactly the same response on exactly the same files. I have checked the permissions on the files in the repository. I have removed some watches that were on some of the files. Bottom line: I have a very repeatable problem with no evidence of a cause I've found. If you have any suggestions, please respond. If this is the incorrect forum, please advise. -Kevin -Original Message- From: info-cvs-bounces+roe2=llnl@nongnu.org [mailto:info-cvs-bounces+roe2=llnl@nongnu.org] On Behalf Of Roe, Kevin L. Sent: Monday, March 15, 2010 4:43 PM To: info-...@nongnu.org Subject: No such file I just checked out my repository and got the error: cvs checkout: cannot write [filename]: No such file or directory What does this mean and how do I fix it? -Kevin -- 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
Re: 1.7.1: cvs version built in is unstable
On Mar 17 12:55, Roe, Kevin L. wrote: Here is what the CVS folks said in response to my e-mail to them. My original message is after their response. -Original Message- From: Larry Jones [mailto:lawrence.jo...@siemens.com] Sent: Wednesday, March 17, 2010 11:31 AM To: Roe, Kevin L. Cc: info-...@nongnu.org Subject: Re: No such file Roe, Kevin L. writes: S- RCS_checkout (/usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, 1.8, , , (function)) cvs checkout: cannot write Utilities/p_change.pl: No such file or directory H, that looks like some kind of a bug/incompatibility in cygwin. You need to ask the cygwin folks 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. Here is the trace for a checkout. I've removed most of the file and left just two similarly named files. One failed and one succeeded. S- RCS_checkout (/usr/gapps/AEAG/cvs_modules/Utilities/p_change.pl,v, S- 1.8, , , (function)) cvs checkout: cannot write Utilities/p_change.pl: No such file or directory S- server_register(p_change.pl, 1.8, , , , , ) Register(p_change.pl, S- 1.8, , , ) Do you have casesensitivity enabled and does the local directory Utilities have another case (like utilities) by any chance? Btw., you missed to send your cygcheck output per the request on http://cygwin.com/problems.html It would give a hint by printing the value of the obcaseinsensitive registry key. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
This is not possible. My computer is disconnected from the internet and has no write capability. This is unfortunate, but not going to change. -Kevin - Btw., you missed to send your cygcheck output per the request on - http://*cygwin.com/problems.html It would give a hint by printing the - value of the obcaseinsensitive registry key. See - http://*cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive -- 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
Re: 1.7.1: cvs version built in is unstable
On Mar 17 13:26, Roe, Kevin L. wrote: This is not possible. My computer is disconnected from the internet and has no write capability. This is unfortunate, but not going to change. -Kevin - Btw., you missed to send your cygcheck output per the request on - http://*cygwin.com/problems.html It would give a hint by printing the - value of the obcaseinsensitive registry key. See - http://*cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive USB sticks exist. But if you don't care, I don't see a reason that I should. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: 1.7.1: cvs version built in is unstable
Like I said, No write capability That includes USB sticks. To get this back on track, obcaseinsensitive set to 0 What should it be? -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, March 17, 2010 1:31 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On Mar 17 13:26, Roe, Kevin L. wrote: This is not possible. My computer is disconnected from the internet and has no write capability. This is unfortunate, but not going to change. -Kevin - Btw., you missed to send your cygcheck output per the request on - http://**cygwin.com/problems.html It would give a hint by printing the - value of the obcaseinsensitive registry key. See - http://**cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive USB sticks exist. But if you don't care, I don't see a reason that I should. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- 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
Re: 1.7.1: cvs version built in is unstable
Roe, Kevin L.: obcaseinsensitive set to 0 What should it be? You could always have a look at the page that Corinna linked to. Oh, and perhaps answer the second part of her question: Do you have casesensitivity enabled and does the local directory Utilities have another case (like utilities) by any chance? Andy -- 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
RE: 1.7.1: cvs version built in is unstable
I did read that page and I reiterate: No write capability That includes USB sticks. I am just trying to get my system working. Please keep this on track. To answer the second part of Corina's question: The Utilities directory is in the repository as Utilities The trace on CVS was for a checkout. I did not modify any of the files and then try to do an update. I just tried to check them out. It has always worked for me before but now it is not. It continues to work from other machines. Please continue to give constructive advice so that I can resolve this issue. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Andy Koppe Sent: Wednesday, March 17, 2010 1:41 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable Roe, Kevin L.: obcaseinsensitive set to 0 What should it be? You could always have a look at the page that Corinna linked to. Oh, and perhaps answer the second part of her question: Do you have casesensitivity enabled and does the local directory Utilities have another case (like utilities) by any chance? Andy -- 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
RE: 1.7.1: cvs version built in is unstable
Ok, I looked at the page about obcaseinsensitive. It is not relevant. My directory is correctly referenced as described below. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Roe, Kevin L. Sent: Wednesday, March 17, 2010 1:46 PM To: Andy Koppe; cygwin@cygwin.com Subject: RE: 1.7.1: cvs version built in is unstable I did read that page and I reiterate: No write capability That includes USB sticks. I am just trying to get my system working. Please keep this on track. To answer the second part of Corina's question: The Utilities directory is in the repository as Utilities The trace on CVS was for a checkout. I did not modify any of the files and then try to do an update. I just tried to check them out. It has always worked for me before but now it is not. It continues to work from other machines. Please continue to give constructive advice so that I can resolve this issue. -Kevin -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Andy Koppe Sent: Wednesday, March 17, 2010 1:41 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable Roe, Kevin L.: obcaseinsensitive set to 0 What should it be? You could always have a look at the page that Corinna linked to. Oh, and perhaps answer the second part of her question: Do you have casesensitivity enabled and does the local directory Utilities have another case (like utilities) by any chance? Andy -- 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
RE: 1.7.1: cvs version built in is unstable
I have performed further tests. I checked out the module on another machine. It worked fine. I copied the repository to my local machine and checked out from there. It worked fine. I copied the previously mentioned files (p_change.pl,v and p_check.pl,v) to new files (p_change2.pl,v and p_check2.pl,v) and then checked out the whole module again from the remote machine (afer deleting the current checked out copy). The old versions continued with the same problems and the new files have a similar response, but it was switched around. i.e.: p_change.pl didn't work p_change2.pl worked p_check.pl worked p_check.pl2 didn't work This is very strange. There seems to be a link between the problem and ssh. -Kevin
Re: 1.7.1: cvs version built in is unstable
Roe, Kevin L: I did read that page and I reiterate: No write capability That includes USB sticks. Yes, so you've said, and my post didn't doubt that in any way. I'm of course highly intrigued by what high-falutin' mystery system you might be working on. Please continue to give constructive advice so that I can resolve this issue. That's pretty rich considering it's taken repeated prompting to get answers to rather straightforward questions. Anyway, now that the case-sensitivity issue seems to have been ruled out, let's go back to an earlier post in this thread: 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 -- 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
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
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
RE: 1.7.1: cvs version built in is unstable
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
Re: 1.7.1: cvs version built in is unstable
On 03/17/2010 03:39 PM, Roe, Kevin L. wrote: 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. The problem is thus that the drive gives bogus inode values, but cygwin does not know how to detect that those values are bogus to use its fallback based on file name hashing. Is this with cygwin 1.7.1 or a snapshot? Corinna has done some work in CVS for various buggy file systems, but you may have encountered yet one more. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: 1.7.1: cvs version built in is unstable
This is Cygwin 1.7.1 -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Eric Blake Sent: Wednesday, March 17, 2010 2:41 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: cvs version built in is unstable On 03/17/2010 03:39 PM, Roe, Kevin L. wrote: 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. The problem is thus that the drive gives bogus inode values, but cygwin does not know how to detect that those values are bogus to use its fallback based on file name hashing. Is this with cygwin 1.7.1 or a snapshot? Corinna has done some work in CVS for various buggy file systems, but you may have encountered yet one more. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://*libvirt.org
1.7.1: cvs version built in is unstable
The built in version of CVS is the unstable feature release version 1.12.13 I am having problems with CVS that I never had before I upgraded cygwin to 1.7.1. Namely: The situation: I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. I then try to update the same module and get the same error on the same files. I check it out again and get exactly the same response on exactly the same files. I have checked the permissions on the files in the repository. I have removed some watches that were on some of the files. Bottom line: I have a very repeatable problem with no evidence of a cause I've found. Has anybody seen this before? How do I downgrade CVS within cygwin down to the stable release 1.11.23 ? -Kevin -- 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
1.7.1: cvs version built in is unstable
I check out a module of my repository (located on a remote machine) and a handful of files do not get downloaded due to the no such file error described below. Try cvs up -d or delete everything and cvs co anew. I could not check out the new directory with a simple cvs up myself. -- -- 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
Re: 1.7.1: cvs version built in is unstable
On 3/16/2010 4:35 PM, Roe, Kevin L. wrote: The built in version of CVS is the unstable feature release version 1.12.13 I am having problems with CVS that I never had before I upgraded cygwin to 1.7.1. [snip] Has anybody seen this before? No. How do I downgrade CVS within cygwin down to the stable release 1.11.23 ? Use setup.exe. In the package chooser, go to the 'Up To Date' page. Find cvs. Click on the word 'keep' until it cycle around to the prev: version, 1.11.22-1 (we've never had a cygwin port of '1.11.23'). While I'm not ruling out a problem with cygwin's current cvs package, I tend to doubt it is the true culprit here. I'd be interested in hearing back (on this list) if cygwin-1.7.1 + cvs-1.11.22 actually fixes your problem; I rather doubt it will. -- 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
