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
  • 69,900
  • 13
  • 192
  • 292
FelixJN
  • 12,616
  • 2
  • 27
  • 48
  • 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](https://unix.stackexchange.com/a/413225/123460) – 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