Re: [boost] [Filesystem] Add features to list all mount paths, determine mount path of a path

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.