This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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:12:26 +0200
- Subject: symlinks in extended attributes
- Reply-to: cygwin-developers at cygwin dot com
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.
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