This is the mail archive of the
mailing list for the Cygwin project.
RE: CIFS symlinks on network share break Cygwin
> We use netapp here too, and we have a mixed NTFS/NT ACLS +
> NFS/Unix perms domain. None of it works well for me from the
> cygwin side, I always find myself having to use the win
> explorer shell extension to change the perms. If I can help
> with some testing or diagnosis or anything, please feel free to
> contact me offlist.
> Can't think of a witty .sigline today....
My issues weren't with the file permissions; it was all about incorrect
symlink behavior. I don't think Cygwin honors the native Unix
permissions/attributes over a CIFS share; I sure wish it would, though.
It would be even cooler if I could create real symlinks on the network
share instead of the fake Cygwin ones. I expect that would require a
lot more from the OS, though. Maybe in Vista - I've heard that there is
a newer SMB/CIFS 2.0 protocol that's supposed to make Windows behave a
lot more like Unix over remote shares. Of course we don't use Vista
here, but there's always hope that in the future this will all
eventually get sorted out.
I keep a Unix shell open so I can change the attributes after creating
the file on the Windows side. It's annoying, because some Windows apps
don't modify files - they delete and rename, so the moment you touch the
file it's lost the permission again. Occasionally I'll use the NetApp
shell extension to do the same, as you mentioned.
Anyway, if you want to try my cygwin1.dll as a way to fix issues with
Unix symlinks over a CIFS NetApp share, let me know and I can send you a
copy directly. I wouldn't recommend using it unless you need it, as
Corinna pointed out that some processes might have problems running in
admin mode correctly with my changes. I've already got a ticket open
with NetApp so there really isn't much to do further until we hear back
from them. An "official" workaround should only happen, I think, after
we've given up on NetApp fixing the problem at the source. I'm all in
favor of avoiding work-arounds for weird behavior (AWAFWB?) whenever
possible. One long look at the filesystem code in Cygwin was enough to
frighten me out of any delusions of adequacy involving changes to Cygwin
file I/O. I have a completely new level of respect for Cygwin at this
- Jonathan Lanier
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html