This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

interoperability between samba, linux-cifs, cywgin and sfu


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

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.

Maybe the following on FILE_TRAVERSE and BYPASS_TRAVERSE_CHECKING is helpful:

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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]