Web lists-archives.com

Re: A Basic Mount Observation

On 5/7/19, Martin McCormick <martin.m@xxxxxxxxxxxxxx> wrote:
> This Summer will mark 30 years since I first laid hands on a
> unix-like system.  I probably was introduced to unix mount points
> very shortly after starting in the unix world which reminded me a
> lot of MSDOS except that there aren't nearly as many gotchas and
> things worked like one would dream they should work so I was
> probably introduced to the concept of the mount point somewhere
> in those early days.
> 	I may just be remembering things the wrong way but it
> seems like that for most of my memory, one could be root and, if
> you cd'd to a mount point, one could mount /dev/whatever on that
> mount point and immediately see the top of the new tree you had
> just mounted.  If you cd'd in to that tree and tried to umount,
> you got the error that the file system was busy which makes sense
> because you are trying to saw off the limb you are sitting on, so
> to speak.
> 	If you cd'd out of the mount point and nobody else was in
> it, you could umount and all was well.
> 	I accidentally discovered now that I can become the root
> user, cd to a mount point and mount something with a subsequent
> ls of my current directory yielding nothing new.  One doesn't see
> the new mount.
> 	If you open another session and look at the mount point,
> the new mount is there.  You can even create a file under the new
> mount which is only visible to you if you didn't cd out of the
> mount point.  Everybody else who looks at that point will see
> what's mounted there and not the test file slipped in under the
> mount.
> 	Has this always been the normal behavior of mount or has
> there been a change?
> 	I see this behavior as being useful like self-modifying
> code which is usually a huge thing to avoid but it was kind of
> interesting to notice.

I didn't fully *cognitively* grasp what you're saying, BUT I did grasp
enough to attempt the following via xfce4-terminal:

$ cd /mountpoint
$ ls
$ *(anticipated) crickets*
$ sudo (YEAH, I KNOW!) mount LABEL=buster-backup /mountpoint
$ ls
$ *mammoth-sized crickets*

*hm* so I next....

$ thunar /mountpoint

That same mountpoint via Thunar file manager (opened via the terminal
at that same mountpoint) is now chock full of the expected
directories, initrd's, vmlinuz's...

*HM* so I next closed Thunar with the thought process being that maybe
opening Thunar finally brought everything to Life. I once again

$ ls
$ *STILL. crickets.*

Nothin' comes back in answer to "ls". I actually figured this NEXT
attempt would FINALLY work. INSTEAD, that which "always does work" has
now been amended to... "almost always does work":

$ ls -ld *
ls: cannot access '*': No such file or directory

??? LOL. In the past, "ls -ld *" has ALWAYS presented query feedback
at times when "ls *" has failed for (system ordained) reasons that so
far zip on by overhead.

Was still not ready to give up SO THEN I lastly tried....

CTRL+SHIFT+T to open a new terminal tab. By default in xfce4-terminal,
that opens up in the same directory that the last active tab was
using. Directories and files now all pull up for "ls" while sitting in

There was another something I did a while back that I can't remember
now, but you had to exit the terminal then reopen it for the desired
effect to take place. I'm halfway thinking it might be something from
Linux From Scratch (LFS) or similar Linux self-education type
exercises. Whatever I'm not remembering, that's what this feels

If it's not quite what you were saying, it's still showing a...
not-quite-anticipated twist on things so that's why I posted. The last
few steps came to mind to test as I was typing this up. :)

Cindy :)
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *