Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Jul 2001 11:46:57 -0700 (PDT)
From:      John Kozubik <john@kozubik.com>
To:        Leo Bicknell <bicknell@ufp.org>
Cc:        freebsd-hackers@FreeBSD.ORG, joelh@gnu.org
Subject:   Re: PR bin/7265 - ln
Message-ID:  <Pine.BSF.4.21.0107111138480.56723-100000@www.kozubik.com>
In-Reply-To: <20010711115929.G63273@ussenterprise.ufp.org>

next in thread | previous in thread | raw e-mail | index | archive | help

I think this sounds reasonable.  If I may, I would suggest two small
changes:

"/sys: Symbolic Link destination src/sys does not exist"

I feel that the actual words "symbolic link" are more appropriate than
"SymLink", but more importantly, as we are striving for clarity in the
error, the error can designate where the link attempted to incorrectly
send the user.

-----
John Kozubik - john@kozubik.com - http://www.kozubik.com



On Wed, 11 Jul 2001, Leo Bicknell wrote:

> 
> I'm going to dig up and old can of worms here, but I think I have
> something new to offer that might fix it.  This is in reference to
> pr bin/7265, which can be found at:
> 
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin%2F7265
> 
> >From the how to repeat section, probably all you need to know:
> 
>     # cd /usr
>     # ln -s src/sys /sys
>     # cd /sys
>     /sys: No such file or directory.
> 
>     (Emit the anguished wails of a tired sysadmin who thinks he's just
>     lost his kernel source.  Repeating this last step is optional.)
> 
> There was a lot of talk about adding flags to ln to fix this problem
> to warn when the destination of a link doesn't exist and the like.
> Rightfully so, many worried that adding flags would cause issues
> (eg with POSIX options later) or that making ln emit messages in this
> case might break shell scripts.  I think these are all valid points
> to one degree or another.
> 
> But then it hit me, the problem isn't with ln.  My origional discussion
> is in the pr, but here's an abbreviated version.  There is no error
> in linking to a non-existing (at the time of link) file/directory. The
> ln should not produce an error, and warnings are, in general, frowned
> upon.  However, there is very much an error from cd, and error that
> is quite poorly reported.
> 
> cd gets this partically right, if you try to cd to an actual file, it
> produces a different error message:
> 
> > touch file
> > cd file
> file: Not a directory.
> 
> Quite clear.
> 
> So, it would appear that the error "No such file or directory" really
> means one of two things (that I've come up with so far, can we think
> of more cases):
> 
> "No such directory."
> "Symlink destination does not exist."
> 
> Let's consider my hypothetical patched cd (which means patched shells,
> because it's a builtin):
> 
>     # cd /usr
>     # ln -s src/sys /sys
>     # cd /sys
>     /sys: Symlink destination does not exist.
> 
> I think our sysadmin would not be wailing, or at least not so much in
> that this error points you right where to look to either verify your
> files are still there, or verify the link is wrong.
> 
> Since there is no change to ln, I don't think anyone can object that
> we're going to break scripts using ln. :-)  The change to cd is only
> in the text of the error message, which is made more specific.  I 
> suppose someone could argue that a script uses that error message,
> but I highly doubt it as the script should be using the return value
> from cd, which would be unchanged.  I also think it's hard to argue
> that error messages that better pinpoint the problem are a bad thing.
> 
> The biggest drawback to this solution is that it will require shells
> to be changed, since as I mentioned before cd is a builtin.  I still
> think that's cleaner than polluting ln, and is also a superior fix
> to the problem.
> 
> Consider the can of worms open, who wants to bite? :-)
> 
> -- 
> Leo Bicknell - bicknell@ufp.org
> Systems Engineer - Internetworking Engineer - CCIE 3440
> Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107111138480.56723-100000>