Hi everybody,
while trying to back up a couple Linux directories to a FAT disk I ran
into a weird situation: I can't create a file called aux.h on the FAT
system!
Here's how to reproduce it:
cd /tmp
dd if=/dev/zero of=vfat_img bs=1M count=1
/sbin/losetup /dev/loop7 vfat_img
/sbin/mkfs.vfat /dev/loop7
mkdir vfat_mnt
mount -t vfat /dev/loop7 vfat_mnt
touch vfat_mnt/auy.h
touch vfat_mnt/aux.h
auy.h is happily created, aux.h gives "touch: setting times of
`vfat_mnt/aux.h': No such file or directory", and no file is created.
This happened to me on the system described below, but I could reproduce
the same behavior on a system booted from RHEL4 CDs, an old Knoppix
(3.4), and friends could reproduce it on other systems, too, so it
doesn't seem to be very related to a specific version.
As a workaround I tar/bzipped my dirs, but that behavior seems very
unusual and doesn't inspire a lot of confidence in vfat... What am I
missing here?
Thanks
Dirk
Here's my system (RHEL4 with updated kernel):
Linux dream.vrac 2.6.15.6 #1 SMP PREEMPT Tue Mar 14 10:41:05 CST 2006
x86_64 x86_64 x86_64 GNU/Linux
Gnu C 3.4.3
Gnu make 3.80
binutils 2.15.92.0.2
util-linux 2.12a
mount 2.12a
module-init-tools 3.1-pre5
e2fsprogs 1.35
reiserfsprogs line
reiser4progs line
pcmcia-cs 3.2.7
quota-tools 3.12.
PPP 2.4.2
nfs-utils 1.0.6
Linux C Library 2.3.4
Dynamic linker (ldd) 2.3.4
Procps 3.2.3
Net-tools 1.60
Kbd 1.12
Sh-utils 5.2.1
udev 039
Modules Loaded loop vmnet vmmon parport_pc lp parport autofs4
sunrpc ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables vfat
fat dm_mod button battery ac nvidia ipv6 usb_storage ohci1394 ohci_hcd
ehci_hcd i2c_nforce2 i2c_core snd_intel8x0 snd_ac97_codec snd_ac97_bus
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc
forcedeth floppy raid0 sata_nv libata sd_mod scsi_mod
On Mon, 20 Mar 2006 15:40:22 -0600 Dirk Reiners wrote:
>
> Hi everybody,
>
> while trying to back up a couple Linux directories to a FAT disk I ran
> into a weird situation: I can't create a file called aux.h on the FAT
> system!
>
> Here's how to reproduce it:
>
> cd /tmp
> dd if=/dev/zero of=vfat_img bs=1M count=1
> /sbin/losetup /dev/loop7 vfat_img
> /sbin/mkfs.vfat /dev/loop7
> mkdir vfat_mnt
> mount -t vfat /dev/loop7 vfat_mnt
> touch vfat_mnt/auy.h
> touch vfat_mnt/aux.h
>
> auy.h is happily created, aux.h gives "touch: setting times of
> `vfat_mnt/aux.h': No such file or directory", and no file is created.
> This happened to me on the system described below, but I could reproduce
> the same behavior on a system booted from RHEL4 CDs, an old Knoppix
> (3.4), and friends could reproduce it on other systems, too, so it
> doesn't seem to be very related to a specific version.
>
> As a workaround I tar/bzipped my dirs, but that behavior seems very
> unusual and doesn't inspire a lot of confidence in vfat... What am I
> missing here?
"AUX" is (was) a reserved "filename" in DOS. The Linux MS-DOS
filesystem preserves (protects) that. The extension part does not
matter; it only checks the first 8 characters of the filename.
You'll need to use a different filesystem or filename...
fs/msdos/namei.c:
for (reserved = reserved_names; *reserved; reserved++)
if (!strncmp(res, *reserved, 8))
return -EINVAL;
/* MS-DOS "device special files" */
static const unsigned char *reserved_names[] = {
"CON ", "PRN ", "NUL ", "AUX ",
"LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ",
"COM1 ", "COM2 ", "COM3 ", "COM4 ",
NULL
};
---
~Randy
> Hi everybody,
>
>while trying to back up a couple Linux directories to a FAT disk I ran
>into a weird situation: I can't create a file called aux.h on the FAT
>system!
>
On DOS et al, there are a number of special filenames, such as
com1:
com2: (and so on)
lpt1:
lpt2: (and so on)
con:
aux
nul
(Try `dir >nul`, it's equivalent to unix's `ls -l >/dev/null` --
aux is the auxiliary port, whatever that is)
It seems only fair to me to not allow creating these files under Linux
either, to avoid problems when booting back to Dos/Windows.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
Followup to: <[email protected]>
By author: "Randy.Dunlap" <[email protected]>
In newsgroup: linux.dev.kernel
>
> "AUX" is (was) a reserved "filename" in DOS. The Linux MS-DOS
> filesystem preserves (protects) that. The extension part does not
> matter; it only checks the first 8 characters of the filename.
> You'll need to use a different filesystem or filename...
>
But this is VFAT, not FAT. It should probably take the reserved name
and mangle it.
>
> /* MS-DOS "device special files" */
> static const unsigned char *reserved_names[] = {
> "CON ", "PRN ", "NUL ", "AUX ",
> "LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ",
> "COM1 ", "COM2 ", "COM3 ", "COM4 ",
> NULL
> };
>
There should be more than that. At the very least there is "CLOCK$"
(arguably anything with $), "MSCD001" (and probably more than 001), as
well as "COM5".."COM8".
-hpa
On Mon, 20 Mar 2006, Dirk Reiners wrote:
>
> Hi everybody,
>
> while trying to back up a couple Linux directories to a FAT disk I ran
> into a weird situation: I can't create a file called aux.h on the FAT
> system!
>
> Here's how to reproduce it:
>
> cd /tmp
> dd if=/dev/zero of=vfat_img bs=1M count=1
> /sbin/losetup /dev/loop7 vfat_img
> /sbin/mkfs.vfat /dev/loop7
> mkdir vfat_mnt
> mount -t vfat /dev/loop7 vfat_mnt
> touch vfat_mnt/auy.h
> touch vfat_mnt/aux.h
>
> auy.h is happily created, aux.h gives "touch: setting times of
> `vfat_mnt/aux.h': No such file or directory", and no file is created.
> This happened to me on the system described below, but I could reproduce
> the same behavior on a system booted from RHEL4 CDs, an old Knoppix
> (3.4), and friends could reproduce it on other systems, too, so it
> doesn't seem to be very related to a specific version.
>
> As a workaround I tar/bzipped my dirs, but that behavior seems very
> unusual and doesn't inspire a lot of confidence in vfat... What am I
> missing here?
>
> Thanks
>
> Dirk
[SNIPPED...]
Special file under DOS: "CON", "AUX", "PRN", and a few others! The
"extension" isn't checked.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.48 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Why on earth does linux enforce this restriction? I'm not sure about dos ( it has been 10+ years since I used it ), but NT will happily create files with those names on either fat or ntfs, provided that you refer to them with an absolute path name. Seeing as how it wasn't really a restriction on the filesystem itself, but rather the fact that those names were predefined by io.sys, I see no reason why linux should prevent you from using them.
Randy.Dunlap wrote:
> "AUX" is (was) a reserved "filename" in DOS. The Linux MS-DOS
> filesystem preserves (protects) that. The extension part does not
> matter; it only checks the first 8 characters of the filename.
> You'll need to use a different filesystem or filename...
>
>
> fs/msdos/namei.c:
>
> for (reserved = reserved_names; *reserved; reserved++)
> if (!strncmp(res, *reserved, 8))
> return -EINVAL;
>
> /* MS-DOS "device special files" */
> static const unsigned char *reserved_names[] = {
> "CON ", "PRN ", "NUL ", "AUX ",
> "LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ",
> "COM1 ", "COM2 ", "COM3 ", "COM4 ",
> NULL
> };
>
>
On Mon, 20 Mar 2006 23:28:19 -0500 Phillip Susi wrote:
> Why on earth does linux enforce this restriction? I'm not sure about dos ( it has been 10+ years since I used it ), but NT will happily create files with those names on either fat or ntfs, provided that you refer to them with an absolute path name. Seeing as how it wasn't really a restriction on the filesystem itself, but rather the fact that those names were predefined by io.sys, I see no reason why linux should prevent you from using them.
The only reason that I could come close to seeing is backwards
compatibility: moving a disk+filesystem back to a real DOS
environment. But that's just not very likely...
> Randy.Dunlap wrote:
> > "AUX" is (was) a reserved "filename" in DOS. The Linux MS-DOS
> > filesystem preserves (protects) that. The extension part does not
> > matter; it only checks the first 8 characters of the filename.
> > You'll need to use a different filesystem or filename...
> >
> >
> > fs/msdos/namei.c:
> >
> > for (reserved = reserved_names; *reserved; reserved++)
> > if (!strncmp(res, *reserved, 8))
> > return -EINVAL;
> >
> > /* MS-DOS "device special files" */
> > static const unsigned char *reserved_names[] = {
> > "CON ", "PRN ", "NUL ", "AUX ",
> > "LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ",
> > "COM1 ", "COM2 ", "COM3 ", "COM4 ",
> > NULL
> > };
---
~Randy
Hi,
On 21 March 2006 00:46, you wrote:
> > Hi everybody,
> >
> >while trying to back up a couple Linux directories to a FAT disk I ran
> >into a weird situation: I can't create a file called aux.h on the FAT
> >system!
> >
> On DOS et al, there are a number of special filenames, such as
>
> com1:
> com2: (and so on)
> lpt1:
> lpt2: (and so on)
> con:
> aux
> nul
>
> (Try `dir >nul`, it's equivalent to unix's `ls -l >/dev/null` --
> aux is the auxiliary port, whatever that is)
>
> It seems only fair to me to not allow creating these files under Linux
> either, to avoid problems when booting back to Dos/Windows.
This is true. smbfs, OTOH, has no such checks, so creating aux.h on an smb share is one easy way to DoS
all WinXP machines using(browsing) this share. Explorer hangs on reading directory with this file.
>
>
> Jan Engelhardt
--
Managing your Territory since the dawn of times ...
On Mon, 2006-03-20 13:50:29 -0800, H. Peter Anvin <[email protected]> wrote:
> > /* MS-DOS "device special files" */
> > static const unsigned char *reserved_names[] = {
> > "CON ", "PRN ", "NUL ", "AUX ",
> > "LPT1 ", "LPT2 ", "LPT3 ", "LPT4 ",
> > "COM1 ", "COM2 ", "COM3 ", "COM4 ",
> > NULL
> > };
> >
>
> There should be more than that. At the very least there is "CLOCK$"
> (arguably anything with $), "MSCD001" (and probably more than 001), as
> well as "COM5".."COM8".
Please divide all the reservednames into two groups: those build-in
into io.sys/msdos.sys/command.com and those that are added on the fly.
For example, "mscd001" is runtime-registered trhough any atapi CD-ROM
driver and this name is/was usually a user-configurable option. (Bad
guys name it 'README'.)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Tue, 21 Mar 2006, Yaroslav Rastrigin wrote:
> Hi,
> On 21 March 2006 00:46, you wrote:
>>> Hi everybody,
>>>
>>> while trying to back up a couple Linux directories to a FAT disk I ran
>>> into a weird situation: I can't create a file called aux.h on the FAT
>>> system!
>>>
>> On DOS et al, there are a number of special filenames, such as
>>
>> com1:
>> com2: (and so on)
>> lpt1:
>> lpt2: (and so on)
>> con:
>> aux
>> nul
>>
>> (Try `dir >nul`, it's equivalent to unix's `ls -l >/dev/null` --
>> aux is the auxiliary port, whatever that is)
>>
>> It seems only fair to me to not allow creating these files under Linux
>> either, to avoid problems when booting back to Dos/Windows.
> This is true. smbfs, OTOH, has no such checks, so creating aux.h on an smb share is one easy way to DoS
> all WinXP machines using(browsing) this share. Explorer hangs on reading directory with this file.
>>
>>
>> Jan Engelhardt
>
> --
> Managing your Territory since the dawn of times ...
Also, CON is a sensitive name on WIN/2000. This can hang the
browser. The "@#+^%!@#" devices still exist:
C:\> copy con xxx.xxx
.... from the shell will wait forever.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.48 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) wrote:
>
> Also, CON is a sensitive name on WIN/2000. This can hang the
> browser. The "@#+^%!@#" devices still exist:
>
> C:\> copy con xxx.xxx
>
> .... from the shell will wait forever.
>
Not quite. This is the same as doing a cp /dev/stdin xxx.xxx on linux.
It will read from stdin until it sees an EOF. On windows, eof is
ctrl-z instead of ctrl-d; hit that and the copy command will finish.
I disagree with this philosophy seeing as how it is possible to create
these files from within windows itself:
echo foo > \\?\c:\aux.h
dir *.h
Volume in drive C has no label.
Volume Serial Number is F064-30D6
Directory of C:\
03/21/2006 10:07a 6 aux.h
1 File(s) 6 bytes
0 Dir(s) 4,584,951,808 bytes free
Creates a file named aux.h in c:\ just fine. Under win2k at least,
explorer only hangs when I try to click on the file. Explorer has
always done really stupid things like this though. I remember when 95
first came out we could create files with high ascii names on the server
like ascii 255, and explorer would happily render it as an underscore
(_), but could not open it or delete it because it was actually trying
to access a directory named "_" rather than ascii 255.
Just because explorer/the win32 api is stupid doesn't mean linux should
be too.
Yaroslav Rastrigin wrote:
>> It seems only fair to me to not allow creating these files under Linux
>> either, to avoid problems when booting back to Dos/Windows.
> This is true. smbfs, OTOH, has no such checks, so creating aux.h on an smb share is one easy way to DoS
> all WinXP machines using(browsing) this share. Explorer hangs on reading directory with this file.
>>
>> Jan Engelhardt
>
>> "AUX" is (was) a reserved "filename" in DOS. The Linux MS-DOS
>> filesystem preserves (protects) that. The extension part does not
>> matter; it only checks the first 8 characters of the filename.
>> You'll need to use a different filesystem or filename...
>
>But this is VFAT, not FAT. It should probably take the reserved name
>and mangle it.
>
NAK. How much more names will you be going to mangle because of FAT
character restrictions? (< and > are one of the chars not allowed in FAT.)
>There should be more than that. At the very least there is "CLOCK$"
>(arguably anything with $), "MSCD001" (and probably more than 001), as
>well as "COM5".."COM8".
>
Objection too. You can create these files without a problem within Win98,
so it shall remain possible under Linux too.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
>> It seems only fair to me to not allow creating these files under Linux
>> either, to avoid problems when booting back to Dos/Windows.
>
>This is true. smbfs, OTOH, has no such checks, so creating aux.h on an smb share is one easy way to DoS
>all WinXP machines using(browsing) this share. Explorer hangs on reading directory with this file.
BTW, what about cifs? And after all, this is not a smbfs check,
but it is something that should be done on the server side.
If you use smbfs to connect two Linux machines, you should be
able to create all the weird names you can imagine (with respect
to what the smb protocol allows). If you have a Windows machine
as the smbfs server, creating 'special files' should be limited
by whatever Windows sees fit.
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
Jan Engelhardt wrote:
>
> NAK. How much more names will you be going to mangle because of FAT
> character restrictions? (< and > are one of the chars not allowed in FAT.)
>
Uhm... that's what VFAT *does*...
-hpa
>> NAK. How much more names will you be going to mangle because of FAT
>> character restrictions? (< and > are one of the chars not allowed in FAT.)
>
> Uhm... that's what VFAT *does*...
>
Hm. How do I check? Under a DOS shell,
echo bla >"illegal>name"
won't work, and creating a new empty dummy text file within Windows
Explorer with this illegal>name won't work either.
(http://jengelh.hopto.org/f/illegal_filename.jpg)
Did I miss some magic WINAPI function that does allow it implicitly
by mangling the name?
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
Jan Engelhardt wrote:
>>>NAK. How much more names will you be going to mangle because of FAT
>>>character restrictions? (< and > are one of the chars not allowed in FAT.)
>>
>>Uhm... that's what VFAT *does*...
>>
>
> Hm. How do I check? Under a DOS shell,
>
> echo bla >"illegal>name"
>
> won't work, and creating a new empty dummy text file within Windows
> Explorer with this illegal>name won't work either.
> (http://jengelh.hopto.org/f/illegal_filename.jpg)
> Did I miss some magic WINAPI function that does allow it implicitly
> by mangling the name?
You're confusing characters which aren't legal *VFAT* names which those
which aren't legal *FAT* (8.3) names.
> is illegal in VFAT as well.
-hpa
>
> You're confusing characters which aren't legal *VFAT* names which those which
> aren't legal *FAT* (8.3) names.
>
Could you please name an illegal FAT name being legal VFAT name?
Jan Engelhardt
--
Jan Engelhardt wrote:
>>You're confusing characters which aren't legal *VFAT* names which those which
>>aren't legal *FAT* (8.3) names.
>>
>
> Could you please name an illegal FAT name being legal VFAT name?
>
"Green Furry Submarine"
-hpa
>> > You're confusing characters which aren't legal *VFAT* names which those
>> > which
>> > aren't legal *FAT* (8.3) names.
>>
>> Could you please name an illegal FAT name being legal VFAT name?
>
> "Green Furry Submarine"
>
Ah well. But aux.h is also forbidden under VFAT, is not it? Or no, because
it's "just" an 8.3 name?
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
Jan Engelhardt wrote:
>>>>You're confusing characters which aren't legal *VFAT* names which those
>>>>which
>>>>aren't legal *FAT* (8.3) names.
>>>
>>>Could you please name an illegal FAT name being legal VFAT name?
>>
>>"Green Furry Submarine"
>>
>
> Ah well. But aux.h is also forbidden under VFAT, is not it? Or no, because
> it's "just" an 8.3 name?
>
It probably depends on how picky you want to be. As far as I know, even
NT will recognize a character device name without leaving \DEV\, even
though \DEV\ has been the "official" device prefix since DOS 2.0.
Probably it would be worth trying to create "aux.h" under XP and see
what happens. Unfortunately I don't have a 'doze system handy at the
moment.
-hpa
On Tue, 21 Mar 2006, H. Peter Anvin wrote:
> Jan Engelhardt wrote:
> >>>>You're confusing characters which aren't legal *VFAT* names which those
> >>>>which
> >>>>aren't legal *FAT* (8.3) names.
> >>>
> >>>Could you please name an illegal FAT name being legal VFAT name?
> >>
> >>"Green Furry Submarine"
> >>
> >
> > Ah well. But aux.h is also forbidden under VFAT, is not it? Or no, because
> > it's "just" an 8.3 name?
> >
>
> It probably depends on how picky you want to be. As far as I know, even
> NT will recognize a character device name without leaving \DEV\, even
> though \DEV\ has been the "official" device prefix since DOS 2.0.
>
> Probably it would be worth trying to create "aux.h" under XP and see
> what happens. Unfortunately I don't have a 'doze system handy at the
> moment.
Fails silently.
> -hpa
>
> -
Vadim Lobanov
>>>>> "H" == H Peter Anvin <[email protected]> writes:
H> It probably depends on how picky you want to be. As far as I know,
H> even NT will recognize a character device name without leaving
H> \DEV\, even though \DEV\ has been the "official" device prefix
H> since DOS 2.0.
H> Probably it would be worth trying to create "aux.h" under XP and
H> see what happens. Unfortunately I don't have a 'doze system handy
H> at the moment.
Unfortunately I do. The desktop won't let me create a file named
'aux' or 'aux.h' at all. I tried fooling it with 'auxx' and then
renaming it it 'aux' but it won't let me using the mouse stuff.
Still wouldn't let me create that name from the 'cmd' shell either.
John
H. Peter Anvin wrote:
> Probably it would be worth trying to create "aux.h" under XP and see
> what happens. Unfortunately I don't have a 'doze system handy at the
> moment.
kernel32.dll's CreateFile() and other apis normally perform translation
which includes special handling for dos device names including AUX. You
can bypass this by prefixing the absolute file name with the string
"\\?\" and this will allow you to create a file named AUX. It also
allows you to reference file names with absolute paths greater than 255
characters.
It's more "treating aux.* the same way as aux". It doesn't fail per se. If
you do "echo test >con.h", it will print to the screen.
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Vadim Lobanov
> Sent: Tuesday, March 21, 2006 11:55 AM
> To: H. Peter Anvin
> Cc: Jan Engelhardt; [email protected]
> Subject: Re: VFAT: Can't create file named 'aux.h'?
>
> On Tue, 21 Mar 2006, H. Peter Anvin wrote:
>
> > Jan Engelhardt wrote:
> > >>>>You're confusing characters which aren't legal *VFAT* names which
> those
> > >>>>which
> > >>>>aren't legal *FAT* (8.3) names.
> > >>>
> > >>>Could you please name an illegal FAT name being legal VFAT name?
> > >>
> > >>"Green Furry Submarine"
> > >>
> > >
> > > Ah well. But aux.h is also forbidden under VFAT, is not it? Or no,
> because
> > > it's "just" an 8.3 name?
> > >
> >
> > It probably depends on how picky you want to be. As far as I know, even
> > NT will recognize a character device name without leaving \DEV\, even
> > though \DEV\ has been the "official" device prefix since DOS 2.0.
> >
> > Probably it would be worth trying to create "aux.h" under XP and see
> > what happens. Unfortunately I don't have a 'doze system handy at the
> > moment.
>
> Fails silently.
>
> > -hpa
> >
> > -
>
> Vadim Lobanov
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
hpa wrote:
> Probably it would be worth trying to create "aux.h" under XP and see
> what happens. Unfortunately I don't have a 'doze system handy at the
> moment.
On my windows xp box, I just ran the following three experiments,
all inside a window brought up by running Start->Run "cmd":
C:\ copy con foo
blah blah blah
^Z
C:\ copy con aux
blah blah blah
C:\ copy con aux.h
blah blah blah
The first experiment above created a file named 'foo',
containing 'blah blah blah'
The second and third experiments both returned to the
command prompt when I pressed "Enter" at the end of the
"blah blah blah", after first complaining:
The system cannot find the file specified.
0 file(s) copied.
This is on a fairly vanilla and uptodate Windows XP SP2.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
Phillip Susi wrote:
> H. Peter Anvin wrote:
>
>> Probably it would be worth trying to create "aux.h" under XP and see
>> what happens. Unfortunately I don't have a 'doze system handy at the
>> moment.
>
>
> kernel32.dll's CreateFile() and other apis normally perform translation
> which includes special handling for dos device names including AUX. You
> can bypass this by prefixing the absolute file name with the string
> "\\?\" and this will allow you to create a file named AUX. It also
> allows you to reference file names with absolute paths greater than 255
> characters.
>
So, in other words, Windows will let you create these files; it will
just make you just through hoops to access them.
Sounds like they should be able to be legitimately created. If the
shortnames are mangled, even DOS or Win9x could access them using the
shortname.
-hpa
"H. Peter Anvin" <[email protected]> writes:
> Phillip Susi wrote:
>> H. Peter Anvin wrote:
>>
>> kernel32.dll's CreateFile() and other apis normally perform translation
>> which includes special handling for dos device names including AUX. You
>> can bypass this by prefixing the absolute file name with the string
>> "\\?\" and this will allow you to create a file named AUX. It also
>> allows you to reference file names with absolute paths greater than 255
>> characters.
>
> So, in other words, Windows will let you create these files; it will
> just make you just through hoops to access them.
>
> Sounds like they should be able to be legitimately created. If the
> shortnames are mangled, even DOS or Win9x could access them using the
> shortname.
Looks like we get a good reason to kill strange reserved names in vfat
(and msdos too?).
Could you/anyone check what shortname is used for "AUX" if it is created
in cmd.exe?
Windows may be storing it as shortname, because it seems to be using
completely separated namespace for devices (I guessed from result of
google).
Thanks.
--
OGAWA Hirofumi <[email protected]>
>>>>> H. Peter Anvin wrote:
> Sounds like they should be able to be legitimately created. If the
> shortnames are mangled, even DOS or Win9x could access them using the
> shortname.
This looks like a mount option is needed. Actually, FAT already has an
option "check={relaxed,normal,strict}".
For example, creation of these files could be enabled in case of
"check=relaxed" (the following is untested):
--- linux-2.6.16/fs/msdos/namei.c~ 2006-03-20 12:32:03.000000000 +0100
+++ linux-2.6.16/fs/msdos/namei.c 2006-03-22 22:37:46.000000000 +0100
@@ -127,7 +127,7 @@
}
while (walk - res < MSDOS_NAME)
*walk++ = ' ';
- if (!opts->atari)
+ if (!opts->atari && opts->name_check != 'r')
/* GEMDOS is less stupid and has no reserved names */
for (reserved = reserved_names; *reserved; reserved++)
if (!strncmp(res, *reserved, 8))
Cheers
Uli
It appears to simply be stored as "aux" under windows. The filesystem
itself has no reserved names. The handling of AUX and CON and friends
is just special case handling done at the win32 api level.
OGAWA Hirofumi wrote:
> Could you/anyone check what shortname is used for "AUX" if it is created
> in cmd.exe?
>
> Windows may be storing it as shortname, because it seems to be using
> completely separated namespace for devices (I guessed from result of
> google).
>
> Thanks.
On Wed, 22 Mar 2006, Phillip Susi wrote:
> It appears to simply be stored as "aux" under windows. The filesystem
> itself has no reserved names. The handling of AUX and CON and friends
> is just special case handling done at the win32 api level.
>
> OGAWA Hirofumi wrote:
>> Could you/anyone check what shortname is used for "AUX" if it is created
>> in cmd.exe?
>>
>> Windows may be storing it as shortname, because it seems to be using
>> completely separated namespace for devices (I guessed from result of
>> google).
>>
>> Thanks.
>
Under win/2000 "aux" can't be created either by using C/C++ or
any of the usual utilities like `ftp`. The returned error-code
is "Permission denied", even from an administrator account.
I have a dual-boot lap-top so I tried to create a file called
"AUX" using `echo "">AUX`, under Linux-2.4.26. The error-code
was "Invalid argument". This is a "vfat" file-system. I was
able to create the device-name "CLOCK$", which is reserved in
DOS. I'm now rebooting the laptop, it should be interesting
to see if it still works! .... Yep. It's not a reserved name
in Win/2000.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.48 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) wrote:
> Under win/2000 "aux" can't be created either by using C/C++ or
> any of the usual utilities like `ftp`. The returned error-code
> is "Permission denied", even from an administrator account.
>
For the third time this thread, yes, you can, you just have to escape
the path name to prevent the win32 api from translating the name to the
non existent AUX device. From a command line you can do:
echo foo > \\?\c:\aux
And it will work just fine. The only place the name "AUX" has any
meaning is in the win32 api layers that translate certain device names
to the real kernel path. The kernel and filesystem will store whatever
name you choose for compatibility with the posix subsystem.
> I have a dual-boot lap-top so I tried to create a file called
> "AUX" using `echo "">AUX`, under Linux-2.4.26. The error-code
> was "Invalid argument". This is a "vfat" file-system. I was
> able to create the device-name "CLOCK$", which is reserved in
> DOS. I'm now rebooting the laptop, it should be interesting
> to see if it still works! .... Yep. It's not a reserved name
> in Win/2000.
>
Ren? Scharfe <[email protected]> writes:
> OGAWA Hirofumi schrieb:
>> Looks like we get a good reason to kill strange reserved names in vfat
>> (and msdos too?).
>>
>> Could you/anyone check what shortname is used for "AUX" if it is created
>> in cmd.exe?
>
> on Windows XP Home SP2 I did:
>
> mkdir d:\test
> cd /d d:\test
> echo 1 > \\?\d:\test\aux
> echo 2 > \\?\d:\test\nul
> echo 3 > \\?\d:\test\nul.x
> echo 4 > \\?\d:\test\nul.longext
> echo 5 > \\?\d:\test\...
> echo 6 > "\\?\d:\test\[];,+="
> echo 7 > "\\?\d:\test\ "
> dir /x > a.txt
>
> And here's the contents of a.txt:
>
> --- snip! ---
> Datentr?ger in Laufwerk D: ist 53_00_00
> Volumeseriennummer: 1002-884F
>
> Verzeichnis von D:\test
>
> 23.03.2006 12:21 <DIR> .
> 23.03.2006 12:21 <DIR> ..
> 23.03.2006 12:21 4 0103~1
> 23.03.2006 12:21 4 7154~1 ...
> 23.03.2006 12:21 0 a.txt
> 23.03.2006 12:21 4 aux
> 23.03.2006 12:21 4 nul
> 23.03.2006 12:21 4 NUL~1.LON nul.longext
> 23.03.2006 12:21 4 nul.x
> 23.03.2006 12:21 4 ______~1 [];,+=
> 8 Datei(en) 28 Bytes
> 2 Verzeichnis(se), 31.506.370.560 Bytes frei
> --- snip! ---
>
> So, no shortname is created for aux on my machine.
Thanks, Phillip and Rene.
It seems the shortname. Because "a.txt" is using same form, and
"no shortname" is meaning a "broken directory entry" in fat spec.
> Of course that doesn't prevent us from creating one in vfat, right?
Yes. We would not need special case for devices.
I'll remove reserved names from vfat/msdos, because many OSes/commands
(even Windows) creates it.
Thanks.
--
OGAWA Hirofumi <[email protected]>
){kind=link}