Right. There's no other way.
> I hope this will work, but I think it will take quite a long time to
> read a complex directory structure.
It's also stupid because there's no way to make sure that the path you just
calculated works for non-root users. Or that it works after another milli-
second or so. For instance:
#/bin/sh
mkdir -p /tmp/1/foo
( sleep 1; foo=1; cd /tmp;
while : ; do bar=$(expr $foo + 1); mv $foo $bar; foo=$bar ; done ) &
cd /tmp/1/foo
sleep 2
/bin/pwd ; sleep 1 ; /bin/pwd ; sleep 1 ; /bin/pwd
->
/tmp/27/foo
/tmp/57/foo
/tmp/86/foo
->
Anything that can be invalidated by unrelated and unprivileged user-mode
operations (remember, it doesn't even have to be the same file system) has
no place within the kernel.
/proc/mounts is the only exception ... which could be improved (provide the
major:minor pairinstead of the device name, and return the mount point's
inode (OK, OK -- a file descriptor for it) when you chdir("/proc/mounts/
LINE-NUMBER"), or something along these lines).
> Are there any other (faster) ways to get the name?
>
Yes. Rethink about why would you need the path in the kernel in the first
place.
--
Must I hold a candle to my shames?
--William Shakespeare [The Merchant of Venice]
--
Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg
Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de
90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42