Strange issue: I have a FAT filesystem on my dual boot laptop and find that under SuSE 9.3 I am unable to create any files called aux.* (e.g. aux, aux.txt, aux.tst).

No such problems on the linux filesystems, nor with slightly differently named files (naux.tst, auxn.tst, etc.).

Also, this is anywhere on the filesystem, independent of (sub) directory.

Any ideas?

Thanks

please post the output of :

mount
id -u

As requested:

/windows/C> mount

/dev/hda8 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda7 on /boot type ext3 (rw,acl,user_xattr)
/dev/hda9 on /home type ext3 (rw,acl,user_xattr)
/dev/hda2 on /windows/C type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0022,utf8=true)
/dev/hda5 on /windows/D type vfat (rw,nosuid,nodev,uid=1000,gid=100,umask=0022,utf8=true)
usbfs on /proc/bus/usb type usbfs (rw)

/windows/C> id -u

1000



The partition with the problem is /dev/hda5.

I can't see anything wrong here.

what happens when you type

touch /windows/D/name_irrelevant

??

In response to your question:

/windows/C> touch /windows/D/name_irrelevant
/windows/C> touch /windows/D/aux
touch: setting times of `/windows/D/aux': No such file or directory
/windows/C> touch /windows/D/naux
/windows/C> touch /windows/D/aux.tst
touch: setting times of `/windows/D/aux.tst': No such file or directory

With as result:

/windows/D> ls -1ltr
total 19200
[SNIP]
drwxr-xr-x 9 user1 users 16384 2005-11-06 14:55 Downloads
-rwxr-xr-x 1 user1 users 0 2005-11-09 16:17 name_irrelevant
-rwxr-xr-x 1 user1 users 0 2005-11-09 16:17 naux

NOTE: it is not specific to the touch command. Any file access generating these files is impossible, giving various errors depending on the program from which it occurs.

hi,
very problematic.. i fall on yourpost, i tried, and same things, probleme with time synchronisation or Invalid Arurment, ...
maybe these is options for the command (like ps -aux=ps aux).
But it's very interresting and i'll go tosearch why it's happen.
I'll come back and we discusse on it.

It does seem a very confusing and strange problem. I ended up recoded my program to give the files involved a different name, but it still puzzles me.

Funny that it is not specific to my system

It must be some very low level issue...

I already tried to switch between BASH and TCSH, using different software to create the files, but nothing makes a difference it seems.

I am very curious to see the explanation to this problem.

well i was wrong !

name is not irrelevant : aux.* is making a difference.

at the moment i'm running cygwin on w2k. trying to create aux.txt:

4:08(/tmp)1257% touch aux.txt
touch: setting times of `aux.txt': Permission denied

and looking at cygwin_help
...and such restrictions appear to apply to your setup also...i'll try it later on a dual boot at home...

ah... that seems to be it! I was not really sure this would be resolved...

I tried it also with some of the other 'names' that you listed (from the cygwin help file) and they seem to display the same behavior!

I suppose it is good to not be able to generate a file that could subsequently crash windows when dual booting into that OS

Thanks!

i found this :
INTRODUCTION

Because AUX, CON, NUL, and PRN are reserved names in Microsoft Windows, Microsoft does not recommend that you use these names as site codes when you install Microsoft Systems Management Server.
at http://support.microsoft.com/default...b;en-us;279868

looking at a 2.4.31 source tree:

in /usr/src/linux/fs/vfat/namei.c

there appears to be code that restricts naming, e.g.,

/* MS-DOS "device special files" */

static const char *reserved3_names[] = {
"con ", "prn ", "nul ", "aux ", NULL
};

static const char *reserved4_names[] = {
"com1 ", "com2 ", "com3 ", "com4 ", "com5 ",
"com6 ", "com7 ", "com8 ", "com9 ",
"lpt1 ", "lpt2 ", "lpt3 ", "lpt4 ", "lpt5 ",
"lpt6 ", "lpt7 ", "lpt8 ", "lpt9 ",
NULL };


/* Characters that are undesirable in an MS-DOS file name */
(and so on)

it makes sense that the kernel developers would keep one from destroying / damaging their other file systems.