open() giving ENOENT when trying to create files with control chars

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

open() giving ENOENT when trying to create files with control chars

Yitzchak Scott-Thoennes
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Eric Blake-2
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Yitzchak Scott-Thoennes
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Martin Koeppe

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=1233&mpage=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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Bill.Hughes
In reply to this post by Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Bill.Hughes
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Yitzchak Scott-Thoennes
In reply to this post by Corinna Vinschen-2
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.orig        2005-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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Eric Blake-2
In reply to this post by Yitzchak Scott-Thoennes
From: Yitzchak Scott-Thoennes <[hidden email]>
>
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Yitzchak Scott-Thoennes
On Fri, Dec 09, 2005 at 12:31:32AM +0000, Eric Blake wrote:

> From: Yitzchak Scott-Thoennes <[hidden email]>
> >
> > 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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Brian Dessent
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Christopher Faylor-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Brian Dessent
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Corinna Vinschen-2
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/

Reply | Threaded
Open this post in threaded view
|

Re: open() giving ENOENT when trying to create files with control chars

Christopher Faylor-2
In reply to this post by Brian Dessent
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/