support for mknod to windows now in cifs vfs

[Martin Koeppe]

On Sun, 20 Nov 2005, Andrew Bartlett wrote:
> On Sat, 2005-11-19 at 16:50 +0100, Martin Koeppe wrote:
>> On Sat, 19 Nov 2005, Andrew Bartlett wrote:
>>> On Fri, 2005-11-18 at 22:30 -0600, Steve French wrote:
>>>> I added the code to cifs vfs to enable it do mknod of block and
>>>> chardevice even if the server does not support the Unix extensions (such
>>>> as Windows).  This requires the "sfu" mount option to be specified
>>>
>>> Any reason why this isn't on by default?
>>
>> My opinion on that is: do _not_ enable by default.
>>
>> Reasons: Basically we now have 2 different ways for exchanging unix
>> file attributes, such as chmod bits, device files, fifos, and
>> symlinks, over the smb/cifs protocol.
>>
>> The first are the unix extensions of samba, and the second is the way,
>> these things are handled by windows with sfu. At least on the client
>> side both ways are mutually exclusive (at very least when reading the
>> attributes).
>
> It is because they are mutually exclusive that we should enable it by
> default.  While many of your points (including in particular the
> cygwin/sfu conflict) are valid, I really want Samba (and the
> linux-cifs-client) to be as simple to use as possible.  This means
> selecting the behaviour that is the most useful to the user, based on
> what we detect of the server (the presence of the unix extensions).

Ok, which option is selected by default doesn't really matter for me. 
If it's good magic, I might even like it. But what I would absolutely 
like to have, is the possibility for manual control of those magic.
And only if you can have manual control, a magic is good for me.

Correct me if I'm wrong, but I didn't find a mount option for 
linux-cifs to disable the samba unix extension mode. You could imagine 
a samba server share, on which some cifs clients need unix extensions, 
and others don't have to use it.

> Has there been any move in cygwin to change to match the SFU behaviour,
> for more consistent storage of this metadata?  What exactly are the
> differences?

For the sfu way, you can read
http://lists.samba.org/archive/linux-cifs-client/2005-May/000856.html
http://lists.samba.org/archive/linux-cifs-client/2005-June/000865.html

As you asked, I had a closer look at the cygwin way, again. First 
of all, all these metadata are stored in the form of explorer .lnk 
files. E.g. if you have a "special-file", then it is stored as 
"special-file.lnk" in the file system. These .lnk files all have the 
dos read-only attribute set. I didn't yet manage to create such a .lnk 
file with explorer such that cygwin recognizes it as special, but I 
didn't try hard yet. I could do, if there is interest in it.

In more detail, you can create block and char nodes, but in a 
subsequent ls, they are shown as symlinks. fifos are shown as fifos, 
but have an file size !=0, i.e. the real size of the .lnk file.
Only symlinks are shown in the same way as on real unix.
(The .lnk files for the symlinks are bigger, about 100bytes, in 
reality.) The set bits seem not to be supported. You can set them with 
no error, but they are not really set, as ls shows.

$ ls -l
total 6144
lrwxrwxrwx  1 martin group     10 Nov 20 13:00 testblock -> :\0:0:61b6
lrwxrwxrwx  1 martin group     10 Nov 20 13:00 testchar -> :\0:0:21b6
drwxr-xr-x  1 martin group      0 Nov 20 13:04 testdir
lrwxrwxrwx  1 martin group      7 Nov 20 13:04 testdirlink -> testdir
prw-rw-rw-  1 martin group    102 Nov 20 13:00 testfifo
-rw-r--r--  1 martin group      0 Nov 20 12:59 testfile
lrwxrwxrwx  1 martin group      8 Nov 20 13:00 testlink -> testfile
-rw-r--r--  1 martin group      0 Nov 20 13:01 testsetfile

One advantage over the sfu way is, that you can follow the symlinks 
with the explorer, even for both types of symlinks, to directories and 
to files. Another advantage is that it works even on FAT fs.

>> One good reason for explicitely disabling the unix extensions are
>> symlinks. If unix ext. are disabled, symlinks are followed on the
>> server, if they are enabled, symlinks are followed at the client. Both
>> modes may be required.
>
> It would seem to me that this is better controlled by having a setting
> for symlinks, rather than overall unix extensions (which includes things
> like allowing filenames with a : in them).

Yes, this seems to be a good idea. This symlink question has been a 
faq entry in a well-known german computer magazine, so there 
definitely is interest in this. The exported fs, as seen by the 
client, should then not support symlinks at all. Because if you create 
a symlink on the client, you wouldn't ever see it as a symlink, as the 
server follows it.


Martin