> on some first vt, with nothing mounted at /mnt...
>
> b64952:~$ cd /mnt
> b64952:/mnt$ ls
> b64952:/mnt$
>
> then on another vt....
>
> b64952:~# mount /dev/cdrom /mnt
> mount: block device /dev/cdrom is write-protected, mounting read-only
> b64952:~#
>
> back to the first vt...
>
> b64952:/mnt$ ls
> /bin/ls: 00_TRANS.TBL: No such file or directory
> [...snip...]
> /bin/ls: UPGRADE.TXT: No such file or directory
>
> b64952:/mnt$ cd /mnt
> b64952:/mnt$ ls
> 00_TRANS.TBL COPYING FAQ.TXT LOWMEM.TXT README.TXT
> [...snip...]
That is certainly an interesting situation. Most traditional UNIX
operating systems will not allow you to do the mount operation since
the directory that you are mounting into is busy by the cwd of your
shell process. I was surprised to learn that linux allowed you to do
that. But I tested it with my recent 2.2.12 kernel and got similar
results.
> I tried this under tcsh as well, and got identical results.
This is not related to shell programs and I expect would give the same
results with all of them.
When I tried to duplicate the results I checked to see what the inode
number of the directory was before and after the mount. Before the
mount I got a non-2 number 4563 or some such as expected. After the
mount I got 2 which is the root of the mounted filesystem. This was
not what *I* expected since I expected it to still say 4563 since I
still had it busy and was where the shell process really thought it
was sitting. It is interesting that the inode number of the cwd of a
process is getting changed out from under it without a cd operation
for that process to have changed it.
If I 'echo *' to only read the directory I can see the contents. But
if I try to access any file under it then the filesystem still thinks
I am in the old location 4563 and not the new mounted location. If I
perform any chdir call then things resync.
I did not look at the code yet. But on the surface it looks to me
like this is a kernel bug. I wonder what Jim will come up with.
Note that linux won't allow you to unmount the directory because it
is busy. But if you never chdir and keep the process in the
interesting state as described above that you can unmount it. Because
it is not really there yet.
Bob
