Mail Archives: cygwin/2008/02/04/10:09:37
On Feb 1 18:06, Jonathan Lanier wrote:
> Newer versions of Cygwin appear to be incompatible with Windows network
> shares on CIFS servers. This incompatibility arises due to the fact
> that the Windows OS seems to return unexpected values for file/directory
> information if the file/directory is a native symlink on the CIFS
> server, which confuses Cygwin. By native, I mean that it is a true
> symlink, created from a *nix client accessing the same network share;
> our CIFS server, a NetApp box, supports true symlinks. Example: The
> native Windows API function GetFileAttributesEx() returns an attribute
> of 0x80 instead of 0x10 when looking up the attribute for a directory
> that is a native symlink (i.e. it incorrectly thinks it's a file, not a
> directory), but *only* when called from a Cygwin application. Compiling
> the same app with -mno-cygwin, or MSVC, returns 0x10 correctly as
> expected.
> [...]
> set_privilege (token, SE_BACKUP_PRIV, true);
> [..]
> What I believe is happening is this. Windows XP normally hides advanced
> non-Windows attributes from a Windows app. Since Windows XP doesn't
> "know" about Unix-style symlinks (let's ignore reparse points, etc. for
> the moment), normally an SMB/CIFS client simply returns the information
> about the file or directory at the end of the link traversal. This is
> the expected behavior; a directory should be treated as a directory with
> a size of 0, a file should be treated as a file with it's true size,
> etc. Now, when you set the SE_BACKUP_PRIV, Windows XP wants the process
> to be in "backup" mode. So, it wants it to see information about the
> actual link, not about the item linked to.
That's not how it works. The file attributes returned to the application
are under full control of the file system. In your case, it's the NetApp
filer. The fact that the same does not happen on Samba shares shows that
quite clearly. Samba always calls stat() on files when retrieving file
information on behalf of a Windows client. The result is that the file
attributes (as well as timestamps, i-node numbers, etc) are always the
attributes of the target file or directory the symlink references.
> This
> "magic" behavior is probably intended for use internally by MS backup
> apps, or possibly for more advanced SFU (Services for Unix)
> compatibility. I don't know *why* they are doing this, only that they
> *are*
"They" are in this case the programmers of the NetApp software. Maybe
it's for some backup software, or maybe it's for some SFU feature.
However, there's something wrong with both ideas.
- If the only change in the information returned to the Windows client
is the attribute bit, the file would be of no much use to a backup
application. It would be stored as a normal file, and there would be
no way to recognize it as symlink when restoring.
- The SE_BACKUP_NAME privilege can only be enabled for accounts which
already have this right in their user token. This is usually only the
case for backup operators and administrators. So, if SFU switches on
the BACKUP right, it would only have an effect on admins and backup
ops. I don't know how SFU works internally, maybe the file access is
always using an SFU daemon process which has BACKUP permissions.
Anyway, the fact that the file returns an attribute of 0x80 does not
mark the file as symlink. Samba also returns 0x80 for all normal
files and for symlinks, so there's no way to recognize that a is a
file but b is a symlink.
> If I comment out the line that sets SE_BACKUP_PRIV to true, everything
> works perfectly.
>
> My questions:
> * Is this a valid fix?
Nope.
> * What are the repercussions of removing the SE_BACKUP_PRIV line?
Admins don't have admin file access anymore.
> * Why was it added in 1.5.20-1 in the first place; i.e. do we really
> want/need all Cygwin processes having backup privilege?
Not all Cygwin processes, but only processes running with admin privs.
> I'm really surprised that more people haven't complained about this,
> because Cygwin is totally broken on CIFS network shares and has been for
> some time. I'm guessing most people are running Samba rather than a
> full-featured CIFS implementation so maybe they haven't encountered this
> yet?
I'm wondering what you mean by "full-featured" here. Samba provides a
full-featured CIFS server with UNIX extensions. For obvious reasons
the UNIX extensions are not provided to Windows clients, though.
There is no good explanation why that NetApp server changes the
file attributes when the Windows client process has the SE_BACKUP_NAME
privilege set. Even if there's a good reason, a valid fix would not
just remove this privilege from the process. I can see two possible
solutions for the future.
- Add a CYGWIN environment variable setting (not very elegant, IMHO)
- Disable the SE_BACKUP_NAME privilege by default. Only enable and
retry to open a file if the first attempt failed.
It's a shame that every file system introduces new weird behaviour
which requires to make all kinds of workarounds necessary. Baeh.
Anyway, this workaround will not be in the release any time soon. For
now I suggest to disable SE_BACKUP_NAME and build your own local version
of Cygwin.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
- Raw text -