Cindy Sue Causey wrote: > On 5/7/19, to...@tuxteam.de <to...@tuxteam.de> wrote: > > > > Makes sense: the current shell (and that is from where we're looking > > at things) keeps the current working directory, CWD, open. This inode > > doesn't go away after a mount -- thus as long as the shell doesn't > > close it (by, e.g., changing to another directory), it will keep > > "seeing" that directory, even if a new process doing an open() will > > "see" the result after the mount. > > Okayyyy.. It sounds like this is a good training point for learning > interoperability that's occurring if there's any way to... maybe point > to images or something that help drive that point on home. I'm almost > already fully grasping at this second because I just worked my own > thought process via terminal. I'm going to reread the above a few more > times then wait for that Linux operation that finally draws it all > together enough to invoke an *ah-HAAA* moment. :)
Each process opens files and closes them. In this case, a directory counts as a special kind of file. An "open" is a process telling the kernel that it wants to use a file. If it's successful, the kernel gives the process a file handle, which is a bit of identifying data. When the process "closes" the file, it hands the file handle back to the kernel. In the meantime, it may have called for read or write operations on the handle. Your shell is a process. When you issue a 'cd' command, it opens the new directory, and when that works, closes the old directory. If it fails, it still has the old directory's file handle and doesn't close it, so you have a "place" to be. When a mount happens, that doesn't change the file handles that have already been issued. They are still valid. When an unmount happens, issued file handles will become invalid if they were part of the mounted filesystem which has now gone away. Does that help? -dsr-
