CIFS extensions for UNIX
urban at teststation.com
Sat Feb 2 04:40:05 GMT 2002
On Sat, 2 Feb 2002, John Newbigin wrote:
> There are a number of constants SMB_xxx_NO_CHANGE. These are all
> 0xFFFFFFFF, a 32 bit number even though they are for a 64 bit data type.
> Should they all then be 0xFFFFFFFFFFFFFFFF?
That would make sense. Does the specification define these values?
Some other specification comments:
I have assumed unique ID and link count is read only from the client side.
If that is the case, perhaps that should be stated explicitly. If it isn't
Any other fields that the client shouldn't be allowed to change?
Size on disk? The client could be allowed to let those values be anything.
Is uniqueid unique for one share? Then the samba implementation is
incorrect when a share is made up of more than one filesystem, since it
just picks the st_ino value. It would need to look at ino + device and
make up a new value.
It could be specified that the uniqueid + devmajor + devminor is unique.
The samba implementation now always looks at st_rdev, for non-devices it
could look at st_dev.
> Make sure that your smbd checks for SMB_SIZE_NO_CHANGE before you try
> changing any file properties or you will end up with some big files.
> PPS: Make sure that SMB_SIZE_NO_CHANGE is the same for the client and
> the server.
The client should check which version of the unix extensions the server
supports. The server should be able to return a number that gives which
version of the specification it implements. If 0xFFFFFFFF is a spec error
the version number should be increased.
TRANS2_QUERY_FS_INFO could be extended ... oh, look, there already is a
SMB_QUERY_CIFS_UNIX_INFO with major and minor numbers.
Hmm, samba 2.2 from CVS defines:
include/trans2.h:#define CIFS_UNIX_MAJOR_VERSION 1
include/trans2.h:#define CIFS_UNIX_MINOR_VERSION 0
But there is a document claiming to be a draft of 2.0:
"CIFS Extensions for UNIX systems v2.0"
And there was some talk on a sharity mailinglist about implementing "2.0".
Don't know if anyone did implement anything, but perhaps a re-numbering is
in order anyway.
More information about the samba-technical