Hidden, system, readonly attributes do not work as expected on OS/2

[guest]

Clients (WinXP and Netdrive) see files on the server, that have the hidden and/or system attribute set.

Clients (WinXP and Netdrive) seem to be able to change hidden, system, readonly attributes, but the attributes don't stick (it appears the server ignores these changes.

Clients (WinXP and Netdrive) can delete files on the server that have readonly attribute set.

[Paul Smedley]

​http://smedley.info/smbdtest.zip is a first attempt at fixing this - attributes of files that preexist on the server at least are recognised with WinXP client.

[guest]

Sjoerd Vissers comment on ecomstation.support.networking:

This formulation does not take into account several features of samba and CIFS. I don't think they are bugs, but they are merely the result of some confusion between classic DOS attributes and the DOS attributes emulation of samba on UNIX file systems.

Samba was developed for UNIX filesystems, not for DOS, Windows and OS/2 filesystems.

UNIX filesytems do not know the DOS attributes hidden, system, readonly, so samba ignores them when it reads the filesystem of the server that can make use of it. This explains the samba behavior under (1) and (3).

Samba makes use of the the UGO user right system of UNIX filesytems and can superimpose on this extra restrictions on samba shares (like read only). Under OS/2 the UGO permissions can only be simulated with security/2.

Because Windows clients expected to see DOS attributes on their own filesystems and on their shares (Windows NT servers), the samba team emulated them on the server. The DOS attributes were laid down in the extended attributes of the server filesystem and had only meaning when used by samba.

See fi: ​http://lists.samba.org/archive/samba-technical/2003-July/030879.html

To make use of it you have enter in smb.conf.

[global] store dos attributes = Yes

If you don't do this (2) will apply.

But when doing this under OS/2 you must realize again that the samba DOS attributes have nothing to do with the classic DOS attributes. Making a file RO via netdrive does not change its DOS atributes on the server, but changes its extended attributes.

You can see this is if you study files made RO via samba with EABrowwser. They have a section USER.DOSATTRIB having the value of 0x12.

[dmik]

This is actually a very major problem as it prevents using the FS on both the client and the server side. One example is SVN. SVN has a control area in each directory (the .svn subdirectory) and it stores all files in R/O mode in there. When it needs to write them, it sets them temporarily to R/W and then sets back to R/W.

Now imagine that you share a SVN tree on an OS/2 machine over Samba. If you create the original tree using the local svn command, all control files will be true R/O. If you then run svn on a share from another machine, the svn commit command will fail when updating e.g. the log file because it will see that the file is R/W (as this is how it is seen through Samba even if it's actually R/O) and won't even try to remove the R/O flag (but it would fail even if it tried, for the same reason of the absence of the proper attribute synchronization).

It's quite obvious IMHO that there must be a direct correspondence between attributes seen over Samba and real file attributes that works both ways. And I actually see no reasons to not implement it (other than the usual lack of time...).

I was thinking that as long as we have kLIBC that supports Unix permission bits, a simple straightforward way of letting Samba server think it is running on a real POSIX machine would solve the problem but it will actually not, because as I found kLIBC itself lacks any support for correspondence between Unix permission bits it stores in EAs and the real DOS attributes. At least, ls -l seems to completely ignore DOS attributes and only shows what's stored in EAs (or 0666 if there is no EAs). So kLIBC itself needs to be fixed too.

BTW, I found an interesting thing. With Samba server 3.0.37 that I'm using at least. If you *clear* the ARCHIVE DOS attribute on a file on the server then the READONLY DOS attribute starts to get mapped correctly and this mapping/sync works both ways. Really strange. If we find a piece of code that does it, it may help a lot. Unfortunately, I don't have time for that right now.

[dmik]

Note about the latter command. This behavior is only observed with store dos attributes = No (expectedly) setting which to Yes is I think completely wrong anyway -- the OS/2 server has a real place to store DOS attrs as opposed to POSIX servers, so storing them in EAs looks, hm, like one more round of mess.

[Herwig Bauernfeind]

​http://msplins06.bon.at/%7Eadmin139/files/attrpack-20071027.zip Scripts provided in this package act as tools to partly work around this problem.

• smbattrib - sets both filesystem and Samba Server attributes of a file (or files)
• attr2smb - synchronizes Samba Server attributes according to filesystem attributes
• smb2attr - synchronizes filesystem attributes according to Samba Server attributes