support for mknod to windows now in cifs vfs

[Andrew Bartlett]

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

I understand the speed problems, which present a more valid reason to
disable this.

> 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

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?

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

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

By expanding the matrix we create more paths and combinations to test,
with more room for error.

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20051120/525e772e/attachment.bin