Date: Wed, 9 Oct 2002 23:11:25 +0200 (CEST) From: Oliver Fromme <olli@secnetix.de> To: freebsd-questions@FreeBSD.ORG Subject: Re: help with ln "linking" Please! [attn manpage authors!] Message-ID: <200210092111.g99LBPht013581@lurza.secnetix.de> In-Reply-To: <tnzntn4egq.ntn@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary W. Swearingen <swear@attbi.com> wrote:
> Oliver Fromme <olli@secnetix.de> writes:
> > Gary W. Swearingen <swear@attbi.com> wrote:
> > > ln [-fhinsv] linked_filename [link_filename]
> > > ln [-fhinsv] linked_filename ... dir_filename
> > > link existing_filename alternate_filename
> > >
> > > This is cleaner, but I think "filename" should be standard in filenames.
> >
> > But it is not a filename.
>
> It's a string which is used by ln(1) and the kernel's directory software
> for a filename; if people want to misuse it for storing PIDs or control
> strings or MP3s, that's an abuse of the system which the manual shouldn't
> bother to accommodate.
No, it is not an abuse. It is utilizing standard UNIX
behaviour, for very good reason.
(I have to admit that I wouldn't want to store an MPEG file
in the string of a symbolic link, though, and I can't
imagine a good reason why someone would want to do that.
Apart from that, the length of symbolic links is limited by
SYMLINK_MAX, which is 1023 bytes.)
> > > Yuck; malloc.conf is nasty.
> >
> > No, it's extremely useful and efficient.
> ...
> > Also, symlinks are an easy way to atomically check and create
> > lockfiles in shell scripts.
>
> Useful, efficient, easy -- and yucky, nasty, kludgy. Apt to break
> if the directory scheme changes or to prevent improvements to same.
I don't know what you mean by "if the directory scheme
changes". The behaviour of symbolic links is well-defined,
exists for ages, and is fundamental to UNIX filesystems.
Let me quote from the SUSv3 / IEEE Std 1003.1-2001 (POSIX)
specification of the symlink() systemcall, which should be
regarded as authoritative:
| int symlink(const char *path1, const char *path2);
|
| The symlink() function shall create a symbolic link
| called <path2> that contains the string pointed to by
| <path1> (<path2> is the name of the symbolic link
| created, <path1> is the string contained in the symbolic
| link).
|
| The string pointed to by <path1> shall be treated only
| as a character string and shall not be validated as a
| pathname.
| [...]
|
| The presence of a hard link guarantees the existence of
| a file, even after the original name has been removed.
| A symbolic link provides no such assurance; in fact, the
| file named by the <path1> argument need not exist when
| the link is created.
I think that's as clear as it can be.
Maybe the problem with the ln(1) manpage stems from the
historical mistake to support hard links and symbolic links
with the same utility ("ln"), even though they are really
fundamentally different concepts. It's two separate system
calls (link(2) for hard links, symlink(2) for symblic
links). It should really be two different utilities (or
at least two different hard links to the same utility),
with two different manual pages.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210092111.g99LBPht013581>