On Mon, 2002-11-11 at 22:14, Andreas Gruenbacher wrote:
>
> I feel somewhat responsible for ext2/ext3, and slightly less so for reiserfs.
> For XFS the right contact would be Nathan Scott, or the linux-xfs list. We
> should try to make a coordinated move.
OK, I'll keep cc'ing both lists if/when I get the patches going.
>
> > [...]
> > > Which information do you want to attach to the symlink that you can't
> > > attach to the object pointed to in the first place?
> >
> > Basically its for multi desktop management.
> > eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N
> > and a few special fake files for running raw scheme code. I may wish to
> > represent /tmp in two views, one with a small icon on the right hand
> > side of the screen just for convenience and on another desktop I might
> > want /tmp with a 64x64 icon and be more prominent on the screen at top
> > left. So as my code stands right now I store
> > user.ferris-icon-name
> > user.ferris-icon-x
> > user.ferris-icon-y
> > as EA on the object itself, be it a file/dir/symlink. This way the
> > symlinks can have different icons and locations.
>
> I see. The benefit over implementing this via special files seems to be that
> the symlink can be used by applications in the usual ways. Still it's seems
> kind of ugly to me...
What solution would you suggest?
I have thought of adapting libferris to support a new symlink format,
using regular files and pretending at its API level that it is a link. I
was still trying to avoid that for now as it opens up a few other
issues.
>
> --Andreas.
>
> _______________________________________________
> acl-devel mailing list
> acl-devel@xxxxxxxxxxx
> http://acl.bestbits.at/mailman/listinfo/acl-devel
--
-----------------------------------------------------
In this world there are only two tragedies.
One is not getting what one wants,
and the other is getting it.
-- Oscar Wilde
http://witme.sourceforge.net/libferris.web/
|