Date: Thu, 19 Dec 1996 04:20:13 GMT From: Arne Henrik Juul <arnej@frida.imf.unit.no> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/2246: symlinks should have their own attributes Message-ID: <199612190420.EAA05926@frida.imf.unit.no> Resent-Message-ID: <199612190230.SAA24196@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 2246 >Category: kern >Synopsis: symlinks should have their own attributes >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Dec 18 18:30:01 PST 1996 >Last-Modified: >Originator: Arne Henrik Juul >Organization: Norwegian University of Technology and Science >Release: FreeBSD 2.2-RELEASE i386 >Environment: Any FreeBSD system. >Description: Some time ago the CSRG found out that it should be possible to do symlinks without the inodes. This would make it possible to store the symlinks in some more effective manner than the traditional form, which uses 1 128byte inode plus one fragment (minimim 512 bytes) per symlink, which is wasteful. Also, some filesystems reportedly store symlinks without any attributes. Therefore the symlink handling was changed to return the attributes of the containing directory instead of the symlink itself, even if the symlink still had an inode. AFAIK, symlinks still have/are stored in inodes, they just aren't used for getting the attributes. This was a mistake. Not only does it differ from what all the unixes out there does, and from what BSD has always done. It also makes it worthless to implement lchown (needed for spec1170 compliance). But it also creates some very real problems. First, ownership. As everybody knows by now, if you create a symlink in /tmp you won't be able to remove it again (unless you're root or "bin"). No problem as long as FreeBSD is only run on network servers (where you only have the administrative staff as users) or on home machines, but what about "normal" multi-user, shell-access boxes? Secondly, timestamps. Normally it's just a pain to get all the symlinks at the bottom when doing "ls -ltra". Today sh-utils 1.14 failed to build because of this as well, which prompted me to do this send-pr (which I have been meaning to write for some time now). >How-To-Repeat: As a normal user on a normal freebsd system: cd /tmp ln -s wherever whatever rm whatever Also, here's my problem report on sh-utils 1.14: + I tried to build sh-utils 1.14 on FreeBSD in my normal manner + when I was stopped by this error from configure: + + checking whether build environment is sane... configure: error: newly created file is older than distributed files! + Check your system clock + + The problem is that the configure script does: + + echo timestamp > conftestfile + # Do this in a subshell so we don't clobber the current shell's + # arguments. FIXME: maybe try `-L' hack like GETLOADAVG test? + if (set X `ls -t $srcdir/configure conftestfile`; test "$2" = conftestfile) + then + + and, of course, in my normal build environment I use a shadow (symlink) + tree to the real sources, so $srcdir/configure is a symlink. + Furthermore, FreeBSD (and NetBSD as well) doesn't return status about + the symlink itself, but instead on the directory it resides in. >Fix: For filesystems where symlinks have inodes/attributes, return them and handle them in the traditional manner. Push the current behavior down to filesystems that actually need it (if any). NEVER modify ufs to do symlinks without inodes, or the wrath of the people will fall upon you again. (Insert one half :-) at will here...) Small symlinks can be fully stored in the inode anyway, giving very small space penalties. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612190420.EAA05926>