Re: quick scripting 'is /P/Q mounted'
On Tue, 13 Mar 2018 15:56:00 -0400
The Wanderer <firstname.lastname@example.org> wrote:
> On 2018-03-13 at 15:39, Joe wrote:
> > On Tue, 13 Mar 2018 14:49:56 +0100 <email@example.com> wrote:
> >> On Tue, Mar 13, 2018 at 10:33:43PM +0900, Mark Fletcher wrote:
> >>> Unless I've misunderstood the question, you can tell if
> >>> something is mounted at a mount point by checking if anything is
> >>> present under the mount point [...]
> >> Not if the file system is really empty (and no, lost+found doesn't
> >> really count, since not all file systems have that).
> > But one use-case is unattended synchronisation, possibly over a
> > network. If the directory is mounted, but with some kind of problem,
> > then a check for mounting could succeed without any data being
> > visible to the synchronising application. In the worst case, the
> > backup directory might be synchronised to an apparently empty
> > one....
> > I prefer to test for the existence of a known lower directory in
> > this case, which tests not only for mounting but for a successful
> > read.
> That test can be spoofed, however, by the creation of a directory with
> the same name (and/or other characteristics) under the mount point
> while the mount is not active.
> Even if you don't think anything malicious is ever going to try to
> spoof this in whatever case is at hand, can you be sure no script
> (or, for that matter, user) will ever attempt to create that
> directory under the mistaken impression that the mount is active?
Reasonably, because the only program likely to create it would be the
synchroniser itself, which should have been prevented from running
because it wasn't there to start with. If it did happen, nothing
would be getting wiped, just a spurious copy created on a drive that
doesn't contain any system stuff, so I wouldn't worry too much. The
wiping of one of the sync targets *might* be catastrophic (and might
lead to the other getting wiped on the next sync) and is completely
Yes, synchronisers do have some protection against this kind of error,
but I like to use belt, braces, and skyhooks when available.
Should I worry about your scenario, I could take it further, with
utterly improbably-named directories or files containing specific data,
but so far I haven't.