Re: open() giving ENOENT when trying to create files with control chars
On Dec 8 23:50, Brian Dessent wrote: Yitzchak Scott-Thoennes wrote: Windows strips trailing spaces and dots (unless the file name consists only of spaces). You need a managed mount to preserve those; otherwise foo , foo., foo. . . . , foo, and a bunch of other spellings all refer to the same file. I attempted to indicate in the message above that I tried it and succeeded in using filenames with spaces on the end (and *different* files named the same except without the spaces). It seems this is *not* an across-the-board Windows limitation. This is probably a difference in the win32 API versus the native API. Correct. In the native API you can create practically every filename which doesn't use invalid characters. But these filenames are not compatible with Win32 functions. Since the bulk of Cygwin is still using the Win32 API, we can't afford to create Win32 incompatible filenames. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Mon, Dec 12, 2005 at 10:49:52AM +0100, Corinna Vinschen wrote: On Dec 8 23:50, Brian Dessent wrote: Yitzchak Scott-Thoennes wrote: Windows strips trailing spaces and dots (unless the file name consists only of spaces). You need a managed mount to preserve those; otherwise foo , foo., foo. . . . , foo, and a bunch of other spellings all refer to the same file. I attempted to indicate in the message above that I tried it and succeeded in using filenames with spaces on the end (and *different* files named the same except without the spaces). It seems this is *not* an across-the-board Windows limitation. This is probably a difference in the win32 API versus the native API. Correct. In the native API you can create practically every filename which doesn't use invalid characters. But these filenames are not compatible with Win32 functions. Since the bulk of Cygwin is still using the Win32 API, we can't afford to create Win32 incompatible filenames. Even if the bulk of cygwin wasn't using the win32 api, we've already seen what happens when we create files which can't be manipulated with standard windows programs. Maybe at some point we'll have a semi-managed mount (because, as you all know managed mounts are terrifically bad because it's possible that they will run into the path length limitation more quickly than regular mounts*) but I don't think we should ever go down the path of blithely creating files with special characters by default. cgf * The horror. The. Horror. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
Christopher Faylor wrote: but I don't think we should ever go down the path of blithely creating files with special characters by default. Now, now... what better way to embrace WJM at its finest than for Cygwin to randomly and inexplicably litter stray CON or you can't delete me . . . files all over the place that steadfastly refuse to be deleted by any windows tools? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Dec 12 08:17, Brian Dessent wrote: Christopher Faylor wrote: but I don't think we should ever go down the path of blithely creating files with special characters by default. Now, now... what better way to embrace WJM at its finest than for Cygwin to randomly and inexplicably litter stray CON or you can't delete me . . . files all over the place that steadfastly refuse to be deleted by any windows tools? I tried this when I introduced the usage of NtCreateFile, but for some reason other developers catched it and actually dared to FIX it. May a thousand hippos fall on them! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Mon, Dec 12, 2005 at 08:17:18AM -0800, Brian Dessent wrote: Christopher Faylor wrote: but I don't think we should ever go down the path of blithely creating files with special characters by default. Now, now... what better way to embrace WJM at its finest than for Cygwin to randomly and inexplicably litter stray CON or you can't delete me . . . files all over the place that steadfastly refuse to be deleted by any windows tools? That's a good point. It is rather fun to chortle and point at the poor saps who managed to create these files using our special tools and then fall back on the Well, it's just like linux! Nyah! Nyah! response. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Fri, Dec 02, 2005 at 11:09:05PM +0100, Corinna Vinschen wrote:
On Dec 2 20:38, Eric Blake wrote:
I'm trying to create a file (on NTFS) with a CR in the name and getting
ENOENT; is it possible for this to work (without a managed mount)?
Welcome to Windows. None of these non-portable characters are
supported in filenames except in managed mounts.
Just to push the point a bit, note the words non-portable.
Moving on to another non-portable problem, I want to create a file
with a space at the end of the name, but cygwin is stripping spaces.
Despite the comment in the code, this does seem to be allowed (though
I suspect it may be via NtCreateFile only, since windows commands
don't seem to handle filenames with spaces at the end well). I tried
this:
--- path.cc.orig2005-10-24 03:33:48.532065000 -0700
+++ path.cc 2005-12-08 11:39:23.237267200 -0800
@@ -482,7 +482,7 @@ path_conv::set_normalized_path (const ch
if (strip_tail)
{
- while (*--p == '.' || *p == ' ')
+ while (*--p == '.') // || *p == ' ')
continue;
*++p = '\0';
}
@@ -957,7 +957,7 @@ out:
/* Windows ignores trailing dots and spaces */
char *tail = NULL;
for (char *p = path; *p; p++)
- if (*p != '.' *p != ' ')
+ if (*p != '.') // *p != ' ')
tail = NULL;
else if (p[1] == '\\')
{
__END__
and with limited testing on XP Pro SP1 didn't find any problems. Is
it possible this space-stripping predates use of NtCreateFile? Are
there problems likely to arise with this (e.g. cygwin calling other
winapi functions that are passed filenames not correctly handling
spaces at the end)?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
From: Yitzchak Scott-Thoennes [EMAIL PROTECTED] Moving on to another non-portable problem, I want to create a file with a space at the end of the name, but cygwin is stripping spaces. Despite the comment in the code, this does seem to be allowed (though I suspect it may be via NtCreateFile only, since windows commands don't seem to handle filenames with spaces at the end well). I tried this: Windows strips trailing spaces and dots (unless the file name consists only of spaces). You need a managed mount to preserve those; otherwise foo , foo., foo. . . . , foo, and a bunch of other spellings all refer to the same file. Unlike in the other case (non-portable characters, which POSIX allows an implementation to reject), the stripping of trailing '.' from filenames is a violation of POSIX, but since Windows is the culprit, cygwin cannot avoid it (except with the overhead of managed mounts). -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Fri, Dec 09, 2005 at 12:31:32AM +, Eric Blake wrote: From: Yitzchak Scott-Thoennes [EMAIL PROTECTED] Moving on to another non-portable problem, I want to create a file with a space at the end of the name, but cygwin is stripping spaces. Despite the comment in the code, this does seem to be allowed (though I suspect it may be via NtCreateFile only, since windows commands don't seem to handle filenames with spaces at the end well). I tried this: Windows strips trailing spaces and dots (unless the file name consists only of spaces). You need a managed mount to preserve those; otherwise foo , foo., foo. . . . , foo, and a bunch of other spellings all refer to the same file. I attempted to indicate in the message above that I tried it and succeeded in using filenames with spaces on the end (and *different* files named the same except without the spaces). It seems this is *not* an across-the-board Windows limitation. Unlike in the other case (non-portable characters, which POSIX allows an implementation to reject), the stripping of trailing '.' from filenames is a violation of POSIX, but since Windows is the culprit, cygwin cannot avoid it (except with the overhead of managed mounts). In the case of ., I'm not sure we would want it allowed it even if Windows made it possible; too backward incompatible with those cases where a filename is specified with a . to indicate no default extension be added (e.g. gcc foo.c -o foo.). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
Yitzchak Scott-Thoennes wrote: Windows strips trailing spaces and dots (unless the file name consists only of spaces). You need a managed mount to preserve those; otherwise foo , foo., foo. . . . , foo, and a bunch of other spellings all refer to the same file. I attempted to indicate in the message above that I tried it and succeeded in using filenames with spaces on the end (and *different* files named the same except without the spaces). It seems this is *not* an across-the-board Windows limitation. This is probably a difference in the win32 API versus the native API. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
Corinna Vinschen corinna-cygwin at cygwin.com writes: On Dec 4 09:29, Yitzchak Scott-Thoennes wrote: ..snip.. http://support.microsoft.com/default.aspx?scid=kb;en-us;117258 is interesting... This is certainly interesting. Using this in Cygwin would require to change the path handling to using UNICODE, though, which is a major undertaking since the path handling throughout Cygwin is plain ASCII right now. Uh, don't forget this is the NTFS API and not the Windows API. If you want to go down this route you may as well add case sensitive file names too... For compatibilty with Windows (not to mention FAT file systems) I wouldn't go anywhere near this, but YMMV. Bill -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Dec 5 10:11, Bill Hughes wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: On Dec 4 09:29, Yitzchak Scott-Thoennes wrote: ..snip.. http://support.microsoft.com/default.aspx?scid=kb;en-us;117258 is interesting... This is certainly interesting. Using this in Cygwin would require to change the path handling to using UNICODE, though, which is a major undertaking since the path handling throughout Cygwin is plain ASCII right now. Uh, don't forget this is the NTFS API and not the Windows API. If you want to go down this route you may as well add case sensitive file names too... That's not quite right. Case-sensitivity is a flag which can be switched on and off at will. It's a property of the driver, not the underlying file system. The underlying file system is obviously capable of storing case-sensitive filenames, the driver just handles characters only differing by case as equal in the default Windows case. The above is converting invalid characters to valid characters. These new characters are still valid characters even when you're working in a plain ASCII (or ISO-8859) environment, since NTFS stores the filenames in UNICODE anyway. I'm not sure until I tried it, of course, but I don't think this will result in problems with Windows, just because your standard font can't display the characters. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
Corinna Vinschen corinna-cygwin at cygwin.com writes: On Dec 5 10:11, Bill Hughes wrote: ..snip.. Uh, don't forget this is the NTFS API and not the Windows API. If you want to go down this route you may as well add case sensitive file names too... That's not quite right. Case-sensitivity is a flag which can be switched on and off at will. It's a property of the driver, not the underlying file system. The underlying file system is obviously capable of storing case-sensitive filenames, the driver just handles characters only differing by case as equal in the default Windows case. The above is converting invalid characters to valid characters. These new characters are still valid characters even when you're working in a plain ASCII (or ISO-8859) environment, since NTFS stores the filenames in UNICODE anyway. OK, I wasn't aware that you could persuade windows to use the case-sensitive abilities of NTFS without hacking. I'm not sure it would be obvious that the FS is capable of case sensitive operations if we didn't already know that - to me it's equally obvious that FAT isn't capable of these. Unless I'm wrong again of course. I'm not sure until I tried it, of course, but I don't think this will result in problems with Windows, just because your standard font can't display the characters. Agreed, not on an NTFS filesystem anyway. I tend to use FAT at home for dual boot machines so I can access the windows disks read/write from linux as the ntfs write ability has had warnings attached for a long time. Come to that I use fat for my XP box so I can use a linux rescue cd when it goes wrong, hence my concerns about cygwin adding value to NTFS ops that wouldn't apply to FAT. Sorry if this is just noise, Bill -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Dec 5 11:20, Bill Hughes wrote: I'm not sure it would be obvious that the FS is capable of case sensitive operations if we didn't already know that - to me it's equally obvious that FAT isn't capable of these. Unless I'm wrong again of course. Well, the GetVolumeInformation function returns the FILE_UNICODE_ON_DISK flag also for FAT filesystems... I don't comment on this further unless I really tried to use it, though :-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Fri, Dec 02, 2005 at 11:09:05PM +0100, Corinna Vinschen wrote: On Dec 2 20:38, Eric Blake wrote: I'm trying to create a file (on NTFS) with a CR in the name and getting ENOENT; is it possible for this to work (without a managed mount)? Welcome to Windows. None of these non-portable characters are supported in filenames except in managed mounts. Just to push the point a bit, note the words non-portable. I did do a bit of looking around before posting, and saw the *?/\|: characters mentioned in several places, but not the 0-0x1f characters. Now, I've looked more and see those officially verboten as well. (Though I also saw a page that documents how 8.3 filenames are formed and seems to say that the *?/\|: characters *are* possible in NTFS filenames.) http://support.microsoft.com/default.aspx?scid=kb;en-us;117258 is interesting... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Dec 4 09:29, Yitzchak Scott-Thoennes wrote: On Fri, Dec 02, 2005 at 11:09:05PM +0100, Corinna Vinschen wrote: On Dec 2 20:38, Eric Blake wrote: I'm trying to create a file (on NTFS) with a CR in the name and getting ENOENT; is it possible for this to work (without a managed mount)? Welcome to Windows. None of these non-portable characters are supported in filenames except in managed mounts. Just to push the point a bit, note the words non-portable. I did do a bit of looking around before posting, and saw the *?/\|: characters mentioned in several places, but not the 0-0x1f characters. Now, I've looked more and see those officially verboten as well. (Though I also saw a page that documents how 8.3 filenames are formed and seems to say that the *?/\|: characters *are* possible in NTFS filenames.) http://support.microsoft.com/default.aspx?scid=kb;en-us;117258 is interesting... This is certainly interesting. Using this in Cygwin would require to change the path handling to using UNICODE, though, which is a major undertaking since the path handling throughout Cygwin is plain ASCII right now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Sun, 4 Dec 2005, Corinna Vinschen wrote: http://support.microsoft.com/default.aspx?scid=kb;en-us;117258 is interesting... This is certainly interesting. Using this in Cygwin would require to change the path handling to using UNICODE, though, which is a major undertaking since the path handling throughout Cygwin is plain ASCII right now. I remember having read about those mappings used by Services for Macintosh and Services for Unix. If I remeber right, they are unfortunately incompatible! SFM uses (from link above): Macintosh ANSI Unicode - 0x01-0x1F 0xF001-0xF01F 0xF020 * 0xF021 / 0xF022 0xF023 0xF024 ? 0xF025 \ 0xF026 | 0xF027 But SFU uses: any invalid ascii char = 0xF000 + ascii code So for 0x01-0x1f the mapping is the same, but e.g. ? is mapped 0x3f = 0xf03f by SFU, and not to 0xf025. Unfortunately I didn't find the source of SFU mapping any more. The only thing I found: http://www.interopsystems.com/tools/forum/tm.aspx?m=1233mpage=1#1236 While searching I found this thread which might be interesting when planning to migrate cygwin from ascii to unicode internally: http://www.opengroup.org/austin/mailarchives/ag/msg08574.html Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
open() giving ENOENT when trying to create files with control chars
I'm trying to create a file (on NTFS) with a CR in the name and getting
ENOENT; is it possible for this to work (without a managed mount)?
Trying all possible characters:
#include stdio.h
#include fcntl.h
#include unistd.h
#include string.h
#include errno.h
#include ctype.h
int main(int argc, char **argv)
{
int fd, c, err;
char filename[4] = foo;
char buf[12];
for (c = 1; c = 255; ++c) {
filename[1] = c;
fd = open (filename, O_WRONLY|O_CREAT|O_EXCL, 0640);
if (fd 0) {
err = errno;
printf (%02x%s: %s\n, c,
(iscntrl (c) ? : (sprintf (buf, (%c), c), buf)),
strerror (err));
} else {
close (fd);
if (unlink (filename))
fprintf (stderr, %x: unlink failed: %s\n, c, strerror (errno));
}
}
return 0;
}
shows all control characters and just a few others not working (obviously
/ and : are out):
01: No such file or directory
02: No such file or directory
03: No such file or directory
04: No such file or directory
05: No such file or directory
06: No such file or directory
07: No such file or directory
08: No such file or directory
09: No such file or directory
0a: No such file or directory
0b: No such file or directory
0c: No such file or directory
0d: No such file or directory
0e: No such file or directory
0f: No such file or directory
10: No such file or directory
11: No such file or directory
12: No such file or directory
13: No such file or directory
14: No such file or directory
15: No such file or directory
16: No such file or directory
17: No such file or directory
18: No such file or directory
19: No such file or directory
1a: No such file or directory
1b: No such file or directory
1c: No such file or directory
1d: No such file or directory
1e: No such file or directory
1f: No such file or directory
22 (): No such file or directory
2a (*): No such file or directory
2f (/): No such file or directory
3a (:): No such file or directory
3c (): No such file or directory
3e (): No such file or directory
3f (?): No such file or directory
5c (\): No such file or directory
7c (|): No such file or directory
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
I'm trying to create a file (on NTFS) with a CR in the name and getting ENOENT; is it possible for this to work (without a managed mount)? Welcome to Windows. None of these non-portable characters are supported in filenames except in managed mounts. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: open() giving ENOENT when trying to create files with control chars
On Dec 2 20:38, Eric Blake wrote: I'm trying to create a file (on NTFS) with a CR in the name and getting ENOENT; is it possible for this to work (without a managed mount)? Welcome to Windows. None of these non-portable characters are supported in filenames except in managed mounts. Just to push the point a bit, note the words non-portable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
