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>