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.