Boost logo

Boost :

Subject: Re: [boost] [Filesystem] Add features to list all mount paths, determine mount path of a path
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-07-12 21:20:45

On 07/12/2010 10:59 AM, Daniel Trebbien wrote:
>> 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
> the source.

On "Unix" systems, you can invoke the lstat system call on the source
file as well as the destination directory. If they have the same st_dev
value, then they are the same filesystem. This suggests that a
get_filesystem_id function that would return this st_dev value on "Unix"
and something else on Windows could be useful. However, that obviously
doesn't guarantee that you will be able to create a hard link, as the
filesystem may not support hard links, or the user may not have
permission, there may not be enough space, etc. The easiest way to
check if a hard link can be made is to simply attempt to create one.
Also, I think along this line you may quickly find yourself out of the
realm of filesystem operations that can usefully be abstracted into a
portable interface.

Listing of mount points is unlikely to be useful as part of a portable
interface, I would think, and therefore probably isn't suitable for
Boost filesystem.

That said, I do think a convenient c++ interface to various "Unix"
functionality (which might make use of Boost.System) could be quite
useful. In many cases, a portable abstraction simply does not suffice,
but it should not be necessary to have to resort to calling the C API
directly. Some people might not approve of a "Unix"-specific library
being in Boost, though.

Boost list run by bdawes at, gregod at, cpdaniel at, john at