Messages in this thread | | | Date | Wed, 15 Apr 1998 22:13:35 +0100 (BST) | From | Riley Williams <> | Subject | Re: 2.0.33: "ln -sf" reacts strange on directories |
| |
Hi Ulrich.
> I have found one odd thing about 2.0.33:
> If I do "ln -sf" for an existing symbolic link, it depends where > the link points to.
> For a file it works as expected (by me).
> For a directory, the modification time of the link's target (the > directory) changes. This is what I do not expect.
> Sorry, if it's not a kernel problem, but for me it seems to be one.
> (GNU fileutils 3.16, libc-5.4.44, kernel 2.0.33, (bash 2.01))
In my case, I have a different problem related to this...
On my system, "ln -sf" NEVER works, but "ln -fs" SOMETIMES works. Neither is guaranteed to work though...and if anybody can tell me why such different behaviour should occur, I'd love to know...
Here's my hardware specs:
Q> Intel P166 with 96M of RAM and 4.5G of hard drive space, Q> organised as follows: Q> Q> /dev/hda = 2.1G Q> 1 = ext2 on / Q> 3 = vfat on /dos/c Q> 4 = extended Q> 5 = ext2 on /backups (mounted RO) Q> Q> /dev/hdb = 2.4G Q> 1 = ext2 on /tmp Q> 2 = ext2 on /root Q> 3 = swap Q> 4 = extended Q> 5 = ext2 on /home Q> 6 = ext2 on /usr Q> 7 = ext2 on /usr/src Q> 8 = ext2 on /usr/doc Q> 9 = ext2 on /home/ftp
Software setup is RedHat 5.0 with glibc 2.0.7-6 rpm's from RedHat as released on 1st April 1998, with kernels 2.0.32 and 2.0.33 both available from LILO, along with MS-DOS 6.22 (the vfat partition does NOT get used for LoseSleep 95, but using that allows me to use long filenames)...
Here's the behaviour I've been noticing:
1. When I update my kernel, I need to tweak the /usr/src/linux link to point to the newly installed kernel. It's a while since I upgraded from 2.0.32 to 2.0.33 but when I did, I did "cd /usr/src" then "mkdir linux-2.0.33" as per usual procedure, then "ln -fs linux-2.0.33 linux" to move the SymLink to the new directory - and had to do that THREE times before it made the change.
2. I recently downloaded and installed the 2.1.95 kernel, and had to move the SymLink to stop that overwriting the 2.0.33 kernel tree, using a similar process. This time it took on the SECOND attempt.
Before anybody asks, I haven't yet rebooted under 2.1.95, so can't comment on its behaviour, but I will be having a look at it tomorrow.
This gives me two questions:
A. What's causing this, and has it been fixed in the 2.1 series kernels?
B. Why can't the kernel archives be created using a directory with the version number included in it, like most other software for Linux is?
Regarding the latter, all it would require is for Linus to create the relevant symlink on his system, then use the SymLink with a trailing / as the relevant parameter to the tar command, so it isn't exactly difficult...
Best wishes from Riley.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |