support for mknod to windows now in cifs vfs

[Martin Koeppe]

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).

For the sfu mode you should also think of running sfu on a windows 
client and storing files on a windows server from within the client's 
sfu environment.

Additionally, I could think of a third variant of unix extensions: The 
one that cygwin uses. In particular I think of the way, cygwin stores 
device files, fifos and symlinks. It is a similar approach as 
interix/sfu uses (store as normal file with special dos mode bits 
set), but of course incompatible. Maybe, one day these get implemented 
in linux-cifs as well.

So we can have the following scenarios:

    server side         |  unix extension mode           |  client
    --------------------+--------------------------------+------------
    samba server        |  samba unix extensions         |  linux-cifs
    win server and sfu  |  sfu extensions                |  linux-cifs
    win svr and cygwin  |  not yet existing cygwin ext.  |  linux-cifs

So I would vote for an explicit cifs mount option, say "unix=",
with these possible values:
unix=none     to disable all unix extensions explicitely
unix=samba    for samba unix extensions
unix=sfu      for sfu mode
unix=cygwin   for the cygwin way of unix extensions

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.



Maybe it's a bit off topic, but similar considerations could be made 
for the samba server. But here, all these different unix extension 
modes could be enabled simultaneously, if one likes to. So all these 
cases are possible:


    server side   |  unix extension mode           |  client
    --------------+--------------------------------+------------
    samba server  |  samba unix extensions         |  linux-cifs
    samba server  |  not yet exist. samba sfu ext. |  win clnt w/sfu
    samba server  |  not yet ex. samba cygwin ext. |  win clnt w/cygwin
    samba server  |  not yet exist. samba sfu ext. |  linux-cifs*
    samba server  |  not yet ex. samba cygwin ext. |  linux-cifs*

*) yes, even these cases would then be thinkable.

Here the extensions are to be implemented into the samba server, so 
that on the samba server, you see the (native) unix file attributes,
but exactly these same attributes are shown on the client.

E.g. the SETFILEBITS discussed before on this thread on 
linux-cifs-client should not simply be stored as ext2 xattr by a samba 
server, but instead should be understood as what they really are, and 
stored as set bits natively, when the (not yet existing) sfu unix 
extension mode is enabled on a samba share. When reading the 
SETFILEBITS ea, the samba server should generate it on the fly based 
on the real set bits of the file in question.


I did not yet report the latter as a samba server wishlist bug, as I 
currently don't know where to do it the best. Maybe this list 
(samba-technical) is not a bad place, but let me know if there are 
better places.


Martin