This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: symlinks in extended attributes
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 4 Jul 2006 10:18:38 +0200
- Subject: Re: symlinks in extended attributes
- References: <20060704081226.GC18873@calimero.vinschen.de>
- Reply-to: cygwin-developers at cygwin dot com
On Jul 4 10:12, Corinna Vinschen wrote:
> In path.cc are two functions, get_symlink_ea and set_symlink_ea, which
> are supposed to write and read symlink info to and from extended
> attributes in a symlink file. The functions are called in
> symlink_worker resp. in symlink_info::check.
>
> As it turns out now, I broke writing symlink info in EAs back in April
> 2004 (see the IMPLEMENT_STATUS_FLAG patch from 2004-04-13), and nobody
> ever realized it! This is obviously because the symlink info is still
> available, just the additional info in the EA is missing.
Coffee deprivation. Actually the symlink EA is written, but it's
never read, given the current code.
> I can fix this with a simple one-line patch, but I'm curious if this
> doesn't rather mean we can drop this functionality entirely.
>
> Every symlink reading requires some sort of CreateFile/ReadFile/
> CloseHandle sequence anyway. Given that the other two symlink readers,
> symlink_info::check_shortcut and symlink_info::check_sysfile are pretty
> streamlined, I'm wondering about the advantage of keeping the info
> another time in the EAs. Is it supposed to be faster? I guess it's
> faster now than before (using NtQueryEaFile instead of BackupRead), but
> is it so much faster than symlink_info::check_shortcut/check_sysfile
> that it's actually worth to keep another code path?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat