Summary: | Attempting to create a symbolic link from a file in current directory to a target directory creates broken symlink | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Miesen <robert.miesen> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | VERIFIED INVALID | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Script automatically exposes the bug in question |
Description
Robert Miesen
2008-01-21 19:22:53 UTC
Created attachment 141504 [details]
Script automatically exposes the bug in question
Kindly read man ln *before* filing bugs... (In reply to comment #2) > Kindly read man ln *before* filing bugs... > I did. This is what it reads: `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. ... So according to the manual, the behavior of ln creating BROKEN symlinks to a file is a BUG. Please reopen this bug. Yeah, except that you got the arguments the other way round... If you have more questions, see http://www.gentoo.org/main/en/support.xml, thanks. No, I have the order of the operators right. I am trying to create a symbolic link to ./Dir that IS CREATED IN ./path/to/DestDir/, not the other way around. BTW, reversing the operators creates a broken symbolic link to ./path/to/DestDir/ in ./Dir/ So unless you have a better argument (with info manual citations to back it up), this is a legitimate bug and deserves to be reopened. (In reply to comment #5) > No, I have the order of the operators right. No, you don't. > I am trying to create a symbolic link to ./Dir that IS CREATED IN > ./path/to/DestDir/, not the other way around. Yeah, so use `ln -s /path/to/DestDir/Dir Dir` as the manpage told you - which will create a symlink named "Dir" in $PWD which is pointing to "/path/to/DestDir/Dir" (and move this out from bugzilla already). Thanks. (In reply to comment #6) > (In reply to comment #5) > > No, I have the order of the operators right. > > No, you don't. > > > I am trying to create a symbolic link to ./Dir that IS CREATED IN > > ./path/to/DestDir/, not the other way around. > > Yeah, so use `ln -s /path/to/DestDir/Dir Dir` as the manpage told you - which > will create a symlink named "Dir" in $PWD which is pointing to > "/path/to/DestDir/Dir" (and move this out from bugzilla already). > > Thanks. > I can see we're just not going to see eye-to-eye on this issue, so why don't we get a third party involved in this and see what they think. OK? This is not neither an arbitration forum, not a support forum. Bugzilla is here for bugs. Your ln usage is clearly incorrect. Once again and for the last time - please take this out from bugzilla This bug is closed and nothing new will happen here. (In reply to comment #7) > I can see we're just not going to see eye-to-eye on this issue, so why don't > we get a third party involved in this and see what they think. OK? I am a third party and you are wrong. (In reply to comment #9) > (In reply to comment #7) > > I can see we're just not going to see eye-to-eye on this issue, so why don't > we get a third party involved in this and see what they think. OK? > > I am a third party and you are wrong. > Ok, where EXACTLY am I wrong? Sofar, I've gotten little more than hubris for arguments and it's really annoying me. To facilitate this discusion, let's take a page out of the info page for ln: 12.2 `ln': Make links between files =================================== `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. * If one TARGET is given, `ln' creates a link to that file in the current directory. * If the `--target-directory' (`-t') option is given, or failing that if the last file is a directory and the `--no-target-directory' (`-T') option is not given, `ln' creates a link to each TARGET file in the specified directory, using the TARGETs' names. .... Bad Example: # Hard coded file names don't move well. ln -s $(pwd)/a /some/dir/ Better Example: # Relative file names survive directory moves and also # work across networked file systems. ln -s afile anotherfile ln -s ../adir/afile yetanotherfile So now that we've got some stuff to work with, I would like to point out that in the first bullet of ln's info page that it says quite clearly that creates a link to the first file from the second. Now if a link is to be created to the first file from the second, how can such a link be made if ln takes in literally the TARGET argument and doesn't process the argument such that either an absolute path is given for the TARGET using the directory or (better, and going along with the apparent preferred uses of ln by GNU) adding a set of relative paths to the TARGET such that the TARGET can be properly reached from the LINKNAME? So as I see it, there are two possibilities for ln's current behavior: 1) There is a BUG in ln's logic for creating symbolic links to a TARGET. or 2) There is a BUG in ln's man and info pages. Either way, this bug is not invalid for the reasons given above. Now, if you still don't believe me, either PROVE that I'm wrong using evidence and direct citations from the manuals or reopen this bug. Restricting this bug to prevent more noise... Since you have been asked multiple times to cease commenting here, any further abuse of bugzilla will result in suspension of your account, thanks for understanding. |