Re: aux.* as filename

[Francky Leyn]

John Cowan wrote:
> Francky Leyn scripsit:
>
>   
> > I have DVD with a file system on. At some place the files aux.c,
> > aux.h and aux.pg are present. If you try to cp, find, tar or whatever,
> > the command "hangs".  I thought: well perhaps those files are corrupt
> > on the DVD. I will try a testcase.  I issue touch aux.c at a place on
> > the C:\. What do I get?  touch: closing `aux.c': Bad file descriptor.
> > Can someone explain me what I encounter here?
> >     
>
> The filenames aux, com1, com2, com3, con, lpt1, lpt2, lpt3, nul, and prn
> are reserved by Windows.  In DOS days, they were the names of devices;
> you can still say "copy foo con" to the DOS shells and the contents of
> foo will be displayed in the shell window.  The pathname of such a file
> and any extension applied to it are completely ignored.  So you cannot
> create files named aux.c or even foo/bar/aux.c.  There is no work-around
> for this.
>
> Similarly, the characters ?, ", <, >, *, |, and : cannot be used in
> Windows filenames or directory names.
>
>   
I have a (perhaps naieve) idea.

Would it not be a good idea that all these cases were handled
correctly by a windows coreutil?
a) so that the command no longer hangs
b) that something better than the cryptic 'bad file specifier' is 
written out
   Eg: aux is a name reserved by windows
c) That under UNIX a warning is issued saying the filename is not Windows
   compatible. I worked for years under UNIX. Never any problems
   with filenames. Now that I'm forced to work under Windows, my
   filesystem is broken at multiple points. I wouldn't have encountered
   this if I was warned.

Regards,

Francky Leyn