Re: symlinks in extended attributes

[Egor Duda <deo at corpit dot ru>]

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.
> 
> 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?


When i was implementing this functionality, i've checked symlink
resolution speed with, IIRC, something like that:

for x in `seq 10`; do for y in `seq 10` do; for z in `seq 10`; do
  mkdir -p a$x/b$y/c$z
  ln -s a$x link-a$x
  ln -s a$x/b$y a$x/link-b$y
  ln -s a$x/b$y/c$z a$x/b$y/link-c$z
done; done; done

and then run (with the cold cache, and with bash, to make sure that
`test' is a built-in)

for x in `seq 10`; do for y in `seq 10` do; for z in `seq 10`; do
  if ! test -f link-a$x/link-b$y/link-c$z; then echo oops!; fi
done; done; done

The difference between EA and non-EA variants was somewhere around
30-50%. I think that it could be explained by the placement by NTFS of
short EA's right into "i-node".

I understand, that a lot could have been changed in cygwin (and in
windows' ntfs driver) since then, so, probably the gain is not that big now.

egor