# [9fans] cifs fails on nodes named aux

183 views

### Ingo Krabbe

Aug 28, 2013, 5:13:43 AM8/28/13
to
Hey,

I found a quite strange effect with cifs (plan9 bell labs edition). I use cifs to mount werc installations from p9p linux servers. Cifs is needed here, as the virtual hosted machine does not support nfs. Maybe I should switch to another userspace filesystem, but for now its cifs.

Any node named aux is translated into AHY9U3~9, of course one-way only, such that I cannot use the AHY9U3~9 node in my plan9 mount.

Renaming to aux2 for example, solves the problem.

I found this when looking at werc/bin/aux, which is a directory.

So I tried this in werc/tpl:
term% ed aux
?aux
i
This is a test
.
wq
15
term% ls -l
--rw-rw-rw- M 166 bill trog 15 Aug 24 11:29 AHY9U3~9
--rw-rw-rw- M 166 bill trog 683 Mar 29 10:03 _debug.tpl
d-rwxrwxrwx M 166 bill trog 0 Mar 29 10:03 _users
--rw-rw-rw- M 166 bill trog 1919 Mar 29 10:03 sitemap.tpl

Maybe I will hunt this further down next weeks...

... Ah I just found out, that ls 'aux' does actually work.

Any hints for debugging this might help.

cheers

ingo krabbe

### Steffen Daode Nurpmeso

Aug 28, 2013, 5:39:33 AM8/28/13
to
Ingo Krabbe <ikrab...@gmail.com> wrote:
|Hey,
|
|I found a quite strange effect with cifs (plan9 bell labs edition). \
|I use cifs to mount werc installations from p9p linux servers. \
|Cifs is needed here, as the virtual hosted machine does not \
|support nfs. Maybe I should switch to another userspace filesystem,\
| but for now its cifs.

cifs is Windows, i think.
If this is the case, then you may run into the issue of implicit
filenames. Search «aux tale», or browse
<heirloom.sourceforge.net/mailx_aux_c.html>.

[.]
|Any hints for debugging this might help.

Maybe.
Ciao

|cheers
|
|ingo krabbe

--steffen

### Ingo Krabbe

Aug 28, 2013, 5:51:34 AM8/28/13
to
> Ingo Krabbe <ikrab...@gmail.com> wrote:
> |Hey,
> |
> |I found a quite strange effect with cifs (plan9 bell labs edition). \
> |I use cifs to mount werc installations from p9p linux servers. \
> |Cifs is needed here, as the virtual hosted machine does not \
> |support nfs. Maybe I should switch to another userspace filesystem,\
> | but for now its cifs.
>
> cifs is Windows, i think.
> If this is the case, then you may run into the issue of implicit
> filenames. Search «aux tale», or browse
> <heirloom.sourceforge.net/mailx_aux_c.html>.

Yes, cifs is used often to mount windows shares, but in this special case I just chose cifs, as NFS has no current user space server and I want to share some filesystems of a virtual host, where I can't add kernel modules.

So actually in my setup I use a Linux CIFS Server (aka. smbd, samba) and the cifs client from plan9.

The shared filesystem originally is a ext2 (or 3 or 4).

Should I really have managed to step over a system design bug that is imported from 1978 till now, through all systems and versions.

Actually, mounting the cifs with a linux mount -t cifs command maps the "aux" filename correctly. So the bug might just have been imported into the plan9 cifs client.

Funny bug.

### erik quanstrom

Aug 28, 2013, 7:26:16 AM8/28/13
to
> > cifs is Windows, i think.
> > If this is the case, then you may run into the issue of implicit
> > filenames. Search «aux tale», or browse
> > <heirloom.sourceforge.net/mailx_aux_c.html>.

as entertaining as this is, is isn't true for dos. there
are no device files on dos in *any* directory. they
are a fiction of the executive. now the effect may
be the same if you're using command.com, but
explorer should be able to deal with that file name.

- erik

### Kurt H Maier

Aug 28, 2013, 9:30:16 AM8/28/13
to
Most certainly not the case -- in explorer (even on Windows 7), File
-> New -> Text Document, then try to name it 'con' and you get a
dialog box with "The specified device name is invalid."

There are actual real reasons we hate DOS and Windows, remember?

khm

### Erik Quanstrom

Aug 28, 2013, 10:26:01 AM8/28/13
to
the claim that the devices are in the directories and thus the file system is still false. even if explorer has some unnecessary code. and plan 9 is not immune from unnecessary weird bits e.g. the export protocol.

- erik

### dexen deVries

Aug 28, 2013, 11:10:16 AM8/28/13
to
On Wednesday 28 of August 2013 10:26:01 Erik Quanstrom wrote:
> the claim that the devices are in the directories and thus the file system
> is still false. even if explorer has some unnecessary code. and plan 9 is
> not immune from unnecessary weird bits e.g. the export protocol.

a somewhat official specification confirms that -- by not listing those magic
files as implied:
http://msdn.microsoft.com/en-us/windows/hardware/gg463084

http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#file_and_directory_names

--
dexen deVries

[[[↓][→]]]

Take care of the luxuries and the necessities will take care of themselves.
-- L. Long

### Kurt H Maier

Aug 28, 2013, 11:39:57 AM8/28/13
to
Quoting dexen deVries <dexen....@gmail.com>:

> On Wednesday 28 of August 2013 10:26:01 Erik Quanstrom wrote:
>> the claim that the devices are in the directories and thus the file system
>> is still false. even if explorer has some unnecessary code. and plan 9 is
>> not immune from unnecessary weird bits e.g. the export protocol.
>
>
>
> a somewhat official specification confirms that -- by not listing those magic
> files as implied:
> http://msdn.microsoft.com/en-us/windows/hardware/gg463084
>

not sure why FAT32 would be relevant here, since he's using a linux
cifs server from an ext fs. samba mangles reserved names much as it
mangles long filenames -- check mangle_hash2.c for examples. when
samba is deciding if a filename needs to be mangled, it checks for
reserved words along with filename length and prohibited characters.
so if samba decides it nees to serve a file named aux, it's going to
ruin it, unless you specifically disable this behavior. for the
record, windows itself does this nonsense as well, unless you've got
the 'cifs extensions for unix' garbage slathered on. the curse of bad
design lives on.

I'm not sufficiently intimate with the cifs server he's using, or plan
9's cifs client, to explain why the behavior is different using the
linux client. There's generally a lot of magic involved with cifs
deciding how best to vomit its guts across the wire, and I've
deliberately avoided learning it where possible. Were this my system,
I'd just switch to 9p.

khm

### Skip Tavakkolian

Aug 28, 2013, 11:49:24 AM8/28/13
to
If you want to solve your problem -- rather than trying to figure out why linux cifs might want to completely emulate windows to a plan9 client  -- i'd suggest importing things from linux with sftpfs or running something like u9fs on linux side, etc.

---------- Forwarded message ----------
From: Steffen Daode Nurpmeso <sda...@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9f...@9fans.net>
Cc:
Date: Wed, 28 Aug 2013 11:39:33 +0200
Subject: Re: [9fans] cifs fails on nodes named aux
Ingo Krabbe <ikrab...@gmail.com> wrote:
|Hey,
|
|I found a quite strange effect with cifs (plan9 bell labs edition). \
|I use cifs to mount werc installations from p9p linux servers. \
|Cifs is needed here, as the virtual hosted machine does not \
|support nfs. Maybe I should switch to another userspace filesystem,\
| but for now its cifs.

cifs is Windows, i think.
If this is the case, then you may run into the issue of implicit
filenames.  Search «aux tale», or browse
<heirloom.sourceforge.net/mailx_aux_c.html>.

### Ingo Krabbe

Aug 28, 2013, 1:45:55 PM8/28/13
to
>
> not sure why FAT32 would be relevant here, since he's using a linux
> cifs server from an ext fs. samba mangles reserved names much as it
> mangles long filenames -- check mangle_hash2.c for examples. when
> samba is deciding if a filename needs to be mangled, it checks for
> reserved words along with filename length and prohibited characters.
> so if samba decides it nees to serve a file named aux, it's going to
> ruin it, unless you specifically disable this behavior. for the
> record, windows itself does this nonsense as well, unless you've got
> the 'cifs extensions for unix' garbage slathered on. the curse of bad
> design lives on.
>
> I'm not sufficiently intimate with the cifs server he's using, or plan
> 9's cifs client, to explain why the behavior is different using the
> linux client. There's generally a lot of magic involved with cifs
> deciding how best to vomit its guts across the wire, and I've
> deliberately avoided learning it where possible. Were this my system,
> I'd just switch to 9p.
>
> khm

I would like to switch to a 9p distribution of files, but how Do I tell this
other people who want to access files on the servers too: "Here I have a better filesystem you never heard of and likely will never hear, as it is used only by the coolest freaks, whom you are no one of."?

As long as you don't have a solution like: "Take this package, install it to your windows and ignore all license security checks. Anything from then on will be done automatically on your system and all systems you are going to install in the future. So you don't need to care, just access these files." (Which is kind of what people think, Windows Filesharing is).

But taking into account that windows is still the "refence system", files that are named aux, con, nul and prn aren't supported by windows and its very easy to show that this is so. So files don't need to exist or shown correctly, that are named this way, as long as I know about that fact and can easily demonstrate that windows truly fails to work and still contains design faults that are a quarter of a century old.

BTW.: The cifs server I use is the debian squeeze samba package (Version ~3.5.6). I'm not sure about all these versions and names, some call it cifs, some call it samba, I still like raider, though it's called twix now. (raider was the name for this twix chocolate, caramel bar, in germany in the 80's ;).

Maybe I will debug this further when I find some time...

Cheers,

Ingo Krabbe

### Steffen Daode Nurpmeso

Aug 28, 2013, 5:49:43 PM8/28/13
to
Oh, sorry, my last Windows was 95B... I still have this old
Cyrix around, but .. it's been a long time.
Likely you are right -- but i guess Gunnar Ritter is just trying
to make it what he thinks is a "haptic experience" for Windows
users.

|- erik

--steffen

### Steffen Daode Nurpmeso

Aug 28, 2013, 5:54:40 PM8/28/13
to
dexen deVries <dexen....@gmail.com> wrote:
|On Wednesday 28 of August 2013 10:26:01 Erik Quanstrom wrote:
|> the claim that the devices are in the directories and thus the file system
|> is still false. even if explorer has some unnecessary code. and plan 9 is
|> not immune from unnecessary weird bits e.g. the export protocol.
|
|a somewhat official specification confirms that -- by not listing those magic
|files as implied:
|http://msdn.microsoft.com/en-us/windows/hardware/gg463084
|
|http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#file_and_directory_names

I've searched for something official for inclusion in my first

|dexen deVries

--steffen

### Steve Simon

Aug 30, 2013, 4:26:37 PM8/30/13
to
> I found a quite strange effect with cifs (plan9 bell labs edition).
> I use cifs to mount werc installations from p9p linux servers.
> Cifs is needed here, as the virtual hosted machine does not support nfs.
> Maybe I should switch to another userspace filesystem, but for now its cifs.

> Any node named aux is translated into AHY9U3~9, of course one-way only,
> such that I cannot use the AHY9U3~9 node in my plan9 mount.

Hi,

I was on holiday last week so I didn't reply. I wrote cifs
and can only say this must be a feature of samba and not cifs.

Cifs knows nothing about reserved names and filename frogs
(illegal characters), it passes names directly through to the
remote server and expects it to either accept or reject them.

Windows dislikes AUX, NUL, PRN, COM[0-9], LPT[0-9], CON and CLOCK\$
irrespective of case; there may be others. These seem to be ghosts of
MSDOS or or was it CP/M, but then again it might have been RSTS-11...

-Steve

### cinap_...@gmx.de

Aug 30, 2013, 5:17:19 PM8/30/13
to
also note, you can still access these magic filenames in windows
thru a unc path.

like \\somemachine\someshare\path\to\magic\file\aux

or when mapped as a dos drive:

\\?\X:\path\to\magic\file\aux

--
cinap