lkml.org 
[lkml]   [1999]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Bug in mkdir(2)
Date
From
In article <Pine.GSO.4.10.9906161627580.27428-100000@weyl.math.psu.edu>,
Alexander Viro <viro@math.psu.edu> writes:
> On Wed, 16 Jun 1999, Linus Torvalds wrote:
>
>>
>>
>> On Wed, 16 Jun 1999, Alexander Viro wrote:
>> >
>> > In other words, if foo is a dangling symlink mkdir("foo/") will merrily
>> > follow it. Which it shouldn't.
>>
>> Why? I think the follows symlink behaviour is the right one, and is
>> consistent with "open" etc. Are there any pressing reasons to not do it?
>
> Oh, well... Looks like it's a really borderline case - everybody seem to
> be doing whatever they want here. In situations when the last component is
> a link and call normally wouldn't follow it adding slashes seems to be
> ignored on Solaris and forces the link expansion on Linux and 4.4BSD...
> I still think that following the link is bogus, but after all, if somebody
> wants to hang let's give him the rope...
>
In a way it's consistent. mkdir DOES follow symlinks in the part of the path
before the last /, so having adding a / cause following symlinks seems
acceptable.

Notice also that if you do:

mkdir q
ln -s q p

lstatting p gives you info on the symlink, while lstatting p/ gives you info
on the directory
(if you have a non super recent ls you can also see it by comparing
ls -l p
and
ls -l p/
)
--
You sound reasonable...Time to up my medication.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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