interoperability between samba, linux-cifs, cywgin and sfu

Martin Koeppe
Thu Dec 1 13:18:00 GMT 2005


[please cc me on replies]

while playing around with a Windows server (2003), a Linux server 
(2.6.11) with Samba (3.0.14a) and a Windows client (2000) with both 
Interix Services for Unix (SFU) (3.5) and Cygwin (1.5.19pre20051130) 
installed, I encountered the following problems or inconsistencies 
when using on the one hand SFU and Cygwin on Windows and Samba network 
shares, and on the other hand when using linux-cifs on Windows shares, 
where locally Cygwin or SFU are used.

Most of these problems have been already discussed, and some of them 
have been solved in between, but I'm cross-posting this summary now to 
all lists involved on that, I hope at least.

Here interoperability is meant as storing special unix file attributes 
(special files, mode bits and user/group ids) in such a way, that they 
ideally are interpreted in the same way by all Windows<->Unix 
connecting software.

(I have marked in [], which of the software mentioned in this mail's 
subject I think should be changed for better interoperability.)

1. storage of special files such as symlinks, fifos, devs  [all]

The way that SFU stores these special files, I tried to explore at:

Cygwin has its own way which I observed by a quick look (so may not 
be completely correct):

A concrete problem on cygwin is that you can create device files, but 
these device files are shown as symlinks instead of as device files 
(even on C:), i.e.

cygwin$ mknod myblock b 0 0
cygwin$ ls -l
lrwxrwxrwx  1 martin mkpasswd  10 Nov 30 23:10 myblock -> :\0:0:61b6
cygwin$ test -b myblock && echo "block"
[ does not echo "block", so is not seen as a block device file ]
cygwin$ test -l myblock && echo "link"
bash: test: -l: unary operator expected
cygwin$ perl -e '-l "myblock" && print "link"'

So "test" dies unexpectedly, but perl doesn't. Another problem.

cygwin$ mkfifo myfifo && ls -l myfifo
prw-rw-rw-  1 martin mkpasswd 102 Nov 30 23:09 myfifo

The fifo is made correctly and shown as such, but has a file size of
102 which is <>0, so not, what I would have expected.

It would be nice if Cygwin could store these files in the same way as 
SFU. And Samba could then convert the SFU method to real device and 
fifo files on the disk. For the cifs client, work has begun to include 
the SFU way:

The only thing one could discuss is how to store symlinks. Cygwin's 
symlinks can be followed in Windows Explorer, whereas SFU symlinks are 
more consistent, as they are named exactly the same on the 
underlying disk, no .lnk appended.

2. test -l does not work [cygwin]

I repeat this here from above for clarity:

cygwin$ test -l a_link && echo "link"
bash: test: -l: unary operator expected
cygwin$ perl -e '-l "a_link" && print "link"'

So "test" dies unexpectedly, but perl doesn't.

3. set file bits  [all]

SFU stores the set file bits in an extended attribute called 
SETFILEBITS, for details see:

Cygwin seems to store the set bits with the help of a special acl 
entry for the "NULL SID". At least chmod 07777 creates such an acl 
entry, and after manually deleting it, the file has no longer set bits 
set in cygwin's opinion.

While both of these methods can be used to store these infos on a 
windows server share, it would be nice, if it could be stored by a 
samba server as well, ideally in such a way, that locally on the samba 
server the file mode is the same as within SFU and/or Cygwin.

The cifs client ideally should show and set these mode bits as well 
from within linux, when one runs Cygwin and/or SFU on a Windows 
server. Work is in progress on that, see:

4. file and directory lower 9 mode bits  [all]

While Corinna has written a good howto on mapping the mode bits on 
Windows ACL entries:
I found one issue not documented there though:

Suppose you have on Windows the following directories:
Now you change the permissions with explorer in the following way:
t2: has access allowed for the current user (non-inherited)
t1: all ACL entries are removed

You can now do the following on a CMD.EXE:
C:\temp> cd t1
Permission denied!
C:\temp> cd t1\t2
So chdir into t2 is possible.

On Cygwin t1 is shown by ls as d---------, but "cd t1/t2" nevertheless 

On interix sfu, t1 is also shown as d---------, but "cd t1/t2" doesn't 
work. Even though it works via Windows Explorer or CMD.EXE.

I don't know which behaviour should be implemented here, I just 
wanted to document the differences.


5. normal files [samba]

Within the SFU environment, normal files from a samba server are 
incorrectly shown as directories, see:

6. uid/gid [samba]
On a samba (3.0.14a and 3.0.21rc1) mounted drive G: sfu's ls shows 
different uids when called with or without -n:

C:\SFU\common>ls.exe -l G:\file.txt
-rwxr--r--  1 3001  3001  6 Dec  1 11:37 /dev/fs/G/file.txt
C:\SFU\common>ls.exe -ln G:\file.txt
-rwxr--r--  1 3000  3001  6 Dec  1 11:37 /dev/fs/G/file.txt

This is only on samba drives, on Windows drives, for the non -n call, 
Windows user names are shown:

C:\SFU\common>ls.exe -l C:\config.sys
-rwxrwxrwx  1 +Administratoren  +SYSTEM  0 May 11  2003 /dev/fs/C/CONFIG.SYS
C:\SFU\common>ls.exe -ln C:\config.sys
-rwxrwxrwx  1 131616            66834    0 May 11  2003 /dev/fs/C/CONFIG.SYS

7. hard links and inode numbers [cygwin]

While Cygwin now reports link count and inode numbers on network 
drives correctly, SFU reports the inode numbers correctly (modulo an 
issue with samba), but the link count on network drives is always 
reported as "1". Maybe that's intentional. See:

8. CreateHardLink() Windows API  [cygwin] [ActivePerl]

The CreateHardLink() Windows API function isn't apparently able to 
create hardlinks on network drives, whereas with the sfu ln utility, 
you can. Both C:\sfu\common\ln.exe and C:\sfu\bin\ln work, where the 
former seems to call the latter internally. As CreateHardLink() is 
used by cygwin (and ActivePerl, too), you cannot with these.

Unfortunately, the error returned by CreateHardLink() doesn't say 
"hardlinks not supported", but it says "file not found":

cygwin$ ln file file2
ln: creating hard link `file2' to `file': No such file or directory

See for a possible solution:


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list