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.

marked as duplicate by muru, Community May 31 at 8:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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 at 7: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. – Fiximan May 31 at 8:37
  • 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 at 8:56
  • 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 at 9: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 at 9:17

Browse other questions tagged or ask your own question.