Subject: Re: [boost] [Filesystem] Add features to list all mount paths, determine mount path of a path
From: Daniel Trebbien (dtrebbien_at_[hidden])
Date: 2010-07-12 13:59:29
> That would be a very questionable feature. On unix there is a single
> filesystem. Things such as "mount paths" are supposed to be abstracted away.
> And what would be the "mount path of the given path" ?
Suppose I had `/dev/hda3` mounted at `/`, `/dev/hdb1` mounted at
`/root`, and `/dev/hda1` mounted at `/mnt/hda1`. I was thinking that
the "mount path" for `/home/daniel` would be `/`; for
`/root/file.txt` it would be `/root`; and for `/mnt/hda1/Documents
and Settings` it would be `/mnt/hda1`.
> Such a path may have
> multiple mout points. Wich one do you return ? And why...?
Return the path of the most-nested mount point. In the examples that I
have given, the "mount path" for `/mnt/hda1/Documents and Settings` is
`/mnt/hda1` because that is more nested than `/`.
> What would [be a] use
> case for this feature ?
One that I was thinking about recently was a way to know whether two
paths are on the same filesystem because in order to create a hard
link to a file, the target often needs to be on the same filesystem as
I think that you can mount the same filesystem to different paths, but
I don't think that this is common practice. Basically, if the mount
paths are different, then you can pretty much say definitively that
they are on different filesystems.
> And why add a function to iterate over all mount points ? I think that only
> makes sense for iterating over windows drives.
It would be a cross-platform way to access some information in the
equivalent of the operating system's fstab.
>> 4. Is the concept of mount paths cross-platform?
> No. Mount points migth be similar to windows drives, but not similar
No? I was almost certain that windows drives are the way that Windows
does mount points.
> And it's mount point, not mount path.
True. I was shortening "mount point path" or "path of mount point",
which both seem stilted to me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk