[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14116: [PATCH] ln: allow to overwrite relative symlink
From: |
Rémy Lefevre |
Subject: |
bug#14116: [PATCH] ln: allow to overwrite relative symlink |
Date: |
Tue, 2 Apr 2013 12:30:46 +0200 |
I'm not sure to understand your first sentence. Resolving the last
component is already the existing behavior, but maybe not the intended one.
Anyway, I agree that the path should be resolved without its last component.
I wrote a new patch for this. I hope that this one will not break anything.
Rémy.
2013/4/2 Pádraig Brady <address@hidden>
> On 04/01/2013 09:10 PM, Rémy Lefevre wrote:
> > Rémy.
> >
> >
> > 2013/4/1 Pádraig Brady <address@hidden <mailto:address@hidden>>
> >
> > On 04/01/2013 03:40 PM, Rémy Lefevre wrote:
> > > Overwriting relative symlink leads to undesirable behavior.
> Consider the
> > > following example:
> > >
> > > # Create some directories
> > > mkdir test
> > > mkdir test/folder1
> > > mkdir test/folder2
> > >
> > > #Create some files
> > > touch test/folder1/file1
> > > touch test/folder1/file2
> > >
> > > #Create a relative symlink in folder2 to file1
> > > ln -sr test/folder1/file1 test/folder2/link
> > >
> > > #Check the link
> > > ls -l test/folder2/link
> > > # Correctly output a link to ../folder1/file1
> > >
> > > #Overwrite the symlink to point to file2
> > > ln -sfr test/folder1/file2 test/folder2/link
> > >
> > > #Check the link
> > > ls -l test/folder2/link
> > > # Wrongly output a link to file2 instead of ../folder1/file2
> > >
> > >
> > > This undesirable behavior is due to a dereferencing of the target
> when the
> > > relative path is computed. Passing CAN_NOLINKS flag to
> > > canonicalize_filename_mode solves the problem.
> >
> > Doing that though breaks `ln -sr target1 target2 dir` where dir is a
> symlink.
> > Also if /some/other/component of the path is a symlink, you probably
> want
> > that resolved? You might even want the final component of the link
> name
> > resolved in some cases. So perhaps the approach here is to only
> disable
> > dereferencing when -n is set, and even then only for the
> last_component()?
> >
> > In other words, `ln -nsf ...` means update the specified link name
> no matter what it is.
> > -n used only be significant when the link name was to a directory,
> > but with -r it's also significant if linking outside its containing
> directory.
> >
> > I'll sort out a patch later.
> >
> > You are right. It breaks any path composed of link. Sorry for this bad
> patch.
> >
> > But could you provide me an example where the final component of the
> link should be resolved ? Does it make sense as the link will be
> overwritten? I must be missing something.
>
> Yes resolving the last component would be a departure from existing
> behavior.
> So it there is no need to conditionalize this on -n, and we just need
> to resolve the path without the last_component() and then tack that on.
>
> thanks,
> Pádraig.
>
patch.diff
Description: Binary data