This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: interoperability between samba, linux-cifs, cywgin and sfu
- From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 1 Dec 2005 12:59:05 -0500
- Subject: Re: interoperability between samba, linux-cifs, cywgin and sfu
- References: <Pine.LNX.4.62.0511302100160.4106@vmdebian.local.koeppe-net.de>
- Reply-to: cygwin at cygwin dot com
On Thu, Dec 01, 2005 at 02:18:10PM +0100, Martin Koeppe wrote:
>Hello,
>
>[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:
>http://lists.samba.org/archive/linux-cifs-client/2005-May/000856.html
>
>Cygwin has its own way which I observed by a quick look (so may not
>be completely correct):
>http://lists.samba.org/archive/linux-cifs-client/2005-November/001080.html
>
>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"'
>link
>
>So "test" dies unexpectedly, but perl doesn't. Another problem.
Cygwin didn't consider a device with a major/minor of zero to be a real
device. This is fixed in CVS.
>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.
I've also fixed this in CVS but I don't see why it would actually
present a problem.
>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"'
>link
>
>So "test" dies unexpectedly, but perl doesn't.
test -l (lowercase L) is not equivalent to perl's -l "function". You
use "test -L" (uppercase L) to check for symlinks. Unsurprisingly
enough, that works fine on cygwin.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/