> i have an invention to share, but considering how small my world is,
> it might be a re-invention.
>
> i put the following line in fstab:
>
> none /TFS tmpfs noexec,nosuid,nodev,size=64m 1 2
>
> and the following lines in boot.local
>
> =============================
> td="TFS"
> if [ -d /$td ]; then
> nm="the.end"
> z="abcdefghijklmnopqrstuvwxyz0123456789"
> (( zc = ${#z} - 1 ))
> for i in `seq 0 $zc`; do
> k=${z:i:1}
> mkdir /$td/$k
> touch /$td/$k/$nm
> for j in `seq 0 $zc`; do
> m=${z:j:1}
> ln -s /$td/$m /$td/$k/$m
> done
> done
> fi
> =================================
>
> with the result that -e is true for files like:
>
> fn=$td"/k/p/l/u/g/r/u/l/e/s/////././/././/./"$nm
>
> if [ -e $fn ]; then echo "happy at last"; fi
>
> apart from "why anyone would want to do such a thing", is this
> a questionable implementation? how much linking can linux
> handle?
>
hi guys, i'd really appreciate some feed back on this symbolic
link issue. i did experience that my system has a limit on the
number of references, but the limit is large enough to be
inconsequential
/TMP/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2
my primary concern is that this freakish usage of symbolic links
puts the system into an extreme situation, the ramifications of which
may not have been considered due to its uncommonness. I really
have no idea what resources are used to resolve such a path. the
closest i come to understanding that is that the limit is put there to
prevent the system from trying to resolve a cycle. any comments
would be greatly appreciated.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list