> I seem to remember that once upon a time, the idea for symlinks was
> that they were magic in some way, and would not have mode bits,
> owner/group, etc. Not having a link count would fit with that.
It would. A filesystem that implements symlinks that way would
presumably refuse attempts to ha
On Fri 29 Jul 2011 at 12:12:22 -0400, Mouse wrote:
> (a) You're forgetting that symlinks have other attributes than the
> link-to string. The most obvious is mode bits (which have no effect
> unless you mount -o symperm, but (a1) that can be done and (a2) they
> can be queried with lstat(2) even i
On Jul 29, 2011, at 10:20 10AM, Emmanuel Dreyfus wrote:
> On Fri, Jul 29, 2011 at 07:10:33AM -0400, Greg Troxel wrote:
>> On Linux, is a hard link to the symlink created for link on any symlink?
>
> On Linux, it always work on the symlink itself, and it is coherent:
> $ mkdir i386
> $ ln -s i386
>> FWIW, I just asked some linux guys about the linux behavior and the
>> answer was "we sell rope".
> That would be my answer too, though I'd probably phrase it as not
> preventing you from doing stupid things because it would also prevent
> you from doing clever things.
(I know, replying to myse
>>> I'd disagree with this as it seems like a nonsensical thing to do.
>> Why?
> Because symlinks are a special type of filesystem object with their
> own semantics
Every filesystem object is. :)
> Also, from a more operational standpoint, because there's no way to
> update a symlink in place, so
On Fri, Jul 29, 2011 at 11:17:46AM -0400, Mouse wrote:
> >> If linux_link(2) seems unreasonable, it could be lazy_link(2),
> >> weak_link(2), braindead_link(2) or whatever.
> > You'll also need to update every filesystem to allow this and update
> > all the various fsck programs to allow filesy
>> What about adding a linux_link(2) that would do exactly what link(2)
>> does but without the FOLLOW flag to NDINIT on the path argument?
How about just fixing link(2) that way?
>> If linux_link(2) seems unreasonable, it could be lazy_link(2),
>> weak_link(2), braindead_link(2) or whatever.
> Y
On Fri, Jul 29, 2011 at 02:20:10PM +, Emmanuel Dreyfus wrote:
> > All in all it seems like a bug for glusterfs to be using link this way.
>
> Given the context, that will not be easy to fix and would have a performance
> hit. This is a filesystem distributed using a distributed hash table,
On Fri, Jul 29, 2011 at 07:10:33AM -0400, Greg Troxel wrote:
> On Linux, is a hard link to the symlink created for link on any symlink?
On Linux, it always work on the symlink itself, and it is coherent:
$ mkdir i386
$ ln -s i386 inst.xxx
$ ln inst.xxx machine
$ ls -lid i386 inst.xxx machine
11356
