lkml.org 
[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH: smart symlink loop detection.


On Tue, 21 Apr 1998, Olivier Galibert wrote:
>
> I'm probably going to sound dumb but what prevents from implementing
> this as, say, /proc/pipe/71371 ?

We could. But why should we? The current Linux behaviour is much better,
and doesn't require those kinds of hacks.

Also, the current linux behaviour allows us to follow links to files that
have been deleted (and in general it just works automatically correctly
for everything, without really having to even think about it):

[torvalds@penguin torvalds]$ echo hello > file
[torvalds@penguin torvalds]$ sleep 1000 < file & rm file
[1] 14648
[torvalds@penguin torvalds]$ cd /proc/14648/fd
[torvalds@penguin fd]$ ll
total 0
lr-x------ 1 torvalds torvalds 64 Apr 20 23:05 0 -> /export/home/penguin/torvalds/file (deleted)
lrwx------ 1 torvalds torvalds 64 Apr 20 23:05 1 -> /dev/ttyp1
lrwx------ 1 torvalds torvalds 64 Apr 20 23:05 2 -> /dev/ttyp1
[torvalds@penguin fd]$ cat 0
hello
[torvalds@penguin fd]$

Sure, we could again do a /proc/deleted/xxxx, but the point is that having
a separate follow_link() that is _not_ the same as readlink+lookup just is
so much cleaner.

Almost anything can be worked around. So I'm not claiming that we couldn't
make the above work, but I _am_ claiming that thanks to the current
follow_link() interface the above is trivially done in the /proc
filesystem, and is very clean. Going to the FreeBSD symlink implementation
would be a very obvious step backwards, in my opinion.

Linus


-
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.045 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site