lkml.org 
[lkml]   [1998]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.062 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site