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
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
