xfs
[Top] [All Lists]

Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs

To: Ethan Benson <erbenson@xxxxxxxxxx>
Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs
From: Vincent Janelle <random@xxxxxxxxxxxxxxxxx>
Date: Tue, 12 Nov 2002 00:19:01 -0800
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <200211120107.gAC17nw20114@xxxxxxxxxxxxxxxxxxxxx>
References: <200211120107.gAC17nw20114@xxxxxxxxxxxxxxxxxxxxx> <20021112081007.GH16831@xxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016
Ethan Benson wrote:

On Tue, Nov 12, 2002 at 11:07:49AM +1000, Ben Martin wrote:
On Tue, 2002-11-12 at 06:46, Ethan Benson wrote:
On Mon, Nov 11, 2002 at 11:04:39PM +1000, Ben Martin wrote:
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.
UGH, apples OSX does this and its gross, `symlinks' you create in the
GUI are useless regular files in the shell.
It wouldn't be quite as painful in ferris because ferris being a library
I add more and more support for it to bash as time goes by. so a cd my-strange-link; would work.

not everyone uses bash.  there is absolutly no acceptable reason to
reinvent("symlink")
not to mention the added overhead involved by involving a file open, seek, and processing this 'symlink' to obtain the info about the real file.


<Prev in Thread] Current Thread [Next in Thread>