3

When mounting a partition into my CWD (mount /path/do/devxy $(pwd)), the current shell session does not recognize it, e.g. find does not show any contents of the partition and umount $(pwd) succeeds despite me being in the directory (keeping it busy).

Only after explicitly entering into the directory via cd . I can browse the files and unmounting fails.

So obviously the information on the changes in my CWD is not passed on. This behaviour is very different from e.g. entering a directory in one session and creating a file into that directory from another one. In this case find's results are up to date.

So how does the shell determine where it is and why is the mounting not visible immediately?

Using GNU bash, version 5.0.3(1) on debian 10.

Considered solved: please check comments.

muru
  • 72,889
FelixJN
  • 13,566
  • 1
    TL;DR: the kernel keeps track of the process's cwd - and it can distinguish between X, and Y mounted on X. – muru May 31 '19 at 07:56
  • This does not seem to fully answer the question, but I think it points in the right direction: the inode information seems not to be updated until a proper directory change, i.e. ls -id . changes after cd . - and so does the output of lsof | grep mnt. I assume inode is the central property to look at here and consider this answered. – FelixJN May 31 '19 at 08:37
  • By this I meant the linked duplicate's answer – FelixJN May 31 '19 at 08:45
  • I think the fact that cd . worked is confusing. I suggest that if it did, it is because your shell is doing something other than literally chdir("."). You could run python and run import os, os.system("sudo mount ..."), os.chdir("."), os.system("ls -id ."). Or in another window, you could run strace -p PID where PID is the value of echo $$ in the shell you run the cd ., and it will show the exact system calls the shell makes. – sourcejedi May 31 '19 at 08:48
  • 2
    ... ah. As I see the linked answer points out, most shells do string manipulation to maintain a "logical" current directory name. This allows cd .. to go "back" after you did cd foo even when foo is a symbolic link. It appears that cd . is doing something similar. – sourcejedi May 31 '19 at 08:56
  • cd . was not the problem, it could have been cd ../dir, cd /path/to/dir or cd $(cwd), too - I wondered about the missing update of my CWD when not "changing" paths. – FelixJN May 31 '19 at 09:00
  • 1
    To be clearer: I think it is confusing that cd . in your shell enters the new mounted directory, but ls . or find . do not show the new mounted directory contents. – sourcejedi May 31 '19 at 09:14
  • 1
    @Fiximan I think what sourcejedi is trying to say is that cd . should ideally be a no-op. If the system call chdir(".") were executed, you won't see the updated (mounted) directory, but the old, underlying one. Instead, the shell sees . and replaces it with the full path that it has kept track of internally. (Try strace -e chdir bash -c 'cd .', for example). – muru May 31 '19 at 09:17
  • @muru Now I understand. Just like the different outcomes of find . vs. find /path/to/dir. Valid point, indeed. – FelixJN May 31 '19 at 09:21

0 Answers0