[conspire] symlinks vs mount --bind [Re: Partitioning revisited briefly]
tony at of.net
Mon Oct 18 13:24:26 PDT 2010
>> A little off the direct topic, but using symlinks can cause trouble-
>> I've been using mount --bind lately instead of symlinks since I've
>> found a couple of instances where symlinking gave trouble.
> Interesting idea. That actually hadn't occurred to me.
> Here's an article about both tmpfs and bind mounts:
> I do worry about recursive commands that will carefully avoid traversing
> symlinks (e.g, rm and mv) but will not hesitate to follow bind
> mounts. Also, problematic as symlinks sometimes are, they're at least a
> bit self-documenting in that you might notice the 'l' special file type
> and the link location data, whereas there's nothing visible in the file
> tree (i.e., unless you happen to look at the 'mount' command's output)
> to remind you that a bind-mounted subtree is now reachable via multiple
> Making one mount be 'ro' (e.g., for backups) and the other rw could help
> address this problem in particular cases. At one point in the past,
> that was supposed to work but didn't yet; I imagine it's fixed by now.
> (Disclaimer: I've not tested anything discussed here.)
Unfortunately that won't address cases like apparmour failing blocking
apps from doing things because paths have been dereferenced. But yes,
all your other observations are right on target.
>  At minimum, you'd want to carefully cultivate the habit of including
> the '--one-file-system' flage with your rm operations. Not a bad idea
> anyway, arguably, albeit it's hideously verbose. With rsync, you get
> the '-x' flag for the same thing.
Indeed. My habitual rsync flags are -aHx and -auHx, often with v and
n added before I do the real thing.
More information about the conspire