[linux-cifs-client] Re: chmod 01777 has different SETFILEBITS EA from chmod 01444

[Martin Koeppe]

Hello Steve,

On Wed, 16 Nov 2005, Steven French wrote:

> To be more precise
>      00777 is 0004
>      01777 is 0E00
>      01444 is 0200
>      02444 is 0400
>      04444 is 0800
>      07777 is 0E00
> (not sure why this is the same as 01777)
>
> Thinking about SETFILEBITS more and Martin's excellent analysis (
> http://lists.samba.org/archive/linux-cifs-client/2005-June/000865.html)
>
> I noticed that
>      chmod 01777 sets SETFILEBITS EA to 0e
> while
>      chmod 01444 sets SETFILEBITS EA to 02
>
> presumably because the latter is undefined (+T) while the latter is 
defined
> (+t)
>
> Any ideas whether there are other combinations to examine (e.g. what 
> would it mean if SETFILEBITS were set to 1)?

I tried to reproduce your results, but I couldn't see what you saw.

My test environment (3 boxes):
- W2K Pro with SFU tools
- W2K3 Server
- Linux

I did the following:
On the W2K I went into the mounted drive N: (from W2K3 server)

   sfu-bash$ cd /dev/fs/N/temp

created a test file and a test dir there,
and executed the following perl script:

   sfu-bash$ perl -e 
'for($i=0;$i<010000;$i++){chmod($i,"testfile","testdir");}'

I sniffed the network traffic with ethereal from the Linux box, while
the perl script was executing. When analyzing the trace, I only found
the following values in SMB Trans2 Request SET_FILE_INFO packages for
smb.ea.data, i.e. the data of SETFILEBITS:

00020000
00040000
00060000
00080000
000A0000
000C0000
000E0000

Unfortunately, I cannot exactly match the chmod mode with the
captured ea data easily, but the values appeared in increasing order,
and I encountered only these 7 values. So my observation from June
2005 seems to be ok, at least for my environment.

I then especially tested chmod 01777 and chmod 01444, but both
resulted in SETFILEBITS=00020000.

I further tested resetting the set bits with chmod 0777, and there,
SETFILEBITS is not set to 00000000, but completely removed, i.e.
ea.len=0

I only did that on a network share to be able to trace the traffic, as
I not yet know an easy method (or a method at all to be honest) to
read the EAs from within Windows from a local disk. Suggestions on
that are welcome.

> I was trying to finish this up in the code.  I wish it were easier 
> to recognize these are there - it is pretty expensive to do that 
> many calls to get xattrs (EAs) for each file (even if only happening 
> when sfu mount option is turned on).

Yes, the trace I did looks expensive, too, when setting and querying
these EAs. Maybe it is worth another mount option, "sfu" and
"sfu-nosetbits", with the latter ignoring the SETFILEBITS EA when
reading (assume always 0) and writing the file mode (mask the mode to
set with 00777). Or maybe the options should be named "sfu-setbits"
and "sfu", as these set bits doesn't seem that useful for me on a
mounted path.

> Someone (probably Martin) also made the point that we need to 
> optionally allow the sfu mount option to work even when Unix 
> extensions are turned on for that mount so Windows clients could see 
> those files.

Not sure what you mean here. I suppose the following: Samba server
with linux-cifs clients (and unix extensions enabled) and with Windows
clients. In this scenario, linux-cifs could read the set bits directly
via unix extensions. The samba server, not the cifs client, should
probably generate the EAs on the fly for the Windows clients, or for a
linux-cifs client with disabled unix extensions. But these SETFILEBITS
EAs should never be stored on a real unix file system such as ext2.
There we have the bits anyway.


Martin