Mail Archives: cygwin/2008/02/04/14:08:56
> 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
OK, thanks for the information. Hopefully NetApp can look into this; if
it's specific to NetApp, or our particular NetApp configuration, they
can fix it, as it seems less elegant for Cygwin to have to work around
this. In the meantime I'll just build our own local version, since it
can't work any worse than the older 1.5.14 did.
Any comments from NetApp? Doesn't, like, Christopher Faylor work for
them, or something? :) I've been told that they troll here...
--
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 -