[Filesystem] Add features to list all mount paths, determine mount path of a path
John Reynolds came up with a great idea for a possible extension to Boost Filesystem, in response to a question on the Boost Users' List about listing all available drives on Windows. The basic idea is to have the ability to list mounted filesystems. I then suggested that `basic_path` could be extended with a new member (e.g.: `mount_path`) that will determine the mount path of the given path, and add a function to iterate over all mount paths. Before I open a feature request, I wanted to ask some questions: 1. Has this idea been discussed before? 2. Is `mount_path` a good name for this? 3. What would be a good name for the function to iterate over all mount paths? 4. Is the concept of mount paths cross-platform?
On Monday 12 July 2010 19:17:44 Daniel Trebbien wrote:
The basic idea is to have the ability to list mounted filesystems. I then suggested that `basic_path` could be extended with a new member (e.g.: `mount_path`) that will determine the mount path of the given path, and add a function to iterate over all mount paths.
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" ? Such a path may have multiple mout points. Wich one do you return ? And why...? What would an use case for this feature ? Maby so you can display space usage? Maby you should add a function to do just that instead ? And why add a function to iterate over all mount points ? I think that only makes sense for iterating over windows drives.
4. Is the concept of mount paths cross-platform?
No. Mount points migth be similar to windows drives, but not similar enougth. And it's mount point, not mount path.
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. 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 enougth.
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.
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.
On 12.07.2010 22:32, Marius Stoica wrote:
On Monday 12 July 2010 19:17:44 Daniel Trebbien wrote:
The basic idea is to have the ability to list mounted filesystems. I then suggested that `basic_path` could be extended with a new member (e.g.: `mount_path`) that will determine the mount path of the given path, and add a function to iterate over all mount paths.
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" ? Such a path may have multiple mout points. Wich one do you return ? And why...? What would an use case for this feature ? Maby so you can display space usage? Maby you should add a function to do just that instead ? And why add a function to iterate over all mount points ? I think that only makes sense for iterating over windows drives.
Although mount points (or Windows drives) are not quite portable, I think this feature would be useful. For instance, knowing whether two paths point to a single device or not would allow for nice optimizations. Recently I was surprised to discover that the standard "rename" function doesn't work if the file to be renamed moves to another device, and I had to manually copy&remove it.
Andrey Semashev wrote:
On 12.07.2010 22:32, Marius Stoica wrote:
The basic idea is to have the ability to list mounted filesystems. I then suggested that `basic_path` could be extended with a new member (e.g.: `mount_path`) that will determine the mount path of the given path, and add a function to iterate over all mount paths. 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
On Monday 12 July 2010 19:17:44 Daniel Trebbien wrote: path" ? Such a path may have multiple mout points. Wich one do you return ? And why...? What would an use case for this feature ? Maby so you can display space usage? Maby you should add a function to do just that instead ? And why add a function to iterate over all mount points ? I think that only makes sense for iterating over windows drives.
Although mount points (or Windows drives) are not quite portable, I think this feature would be useful. For instance, knowing whether two paths point to a single device or not would allow for nice optimizations. Recently I was surprised to discover that the standard "rename" function doesn't work if the file to be renamed moves to another device, and I had to manually copy&remove it.
I think the advice here, just like with creating hard links, is try a rename - if it doesn't work try a copy and delete. It is not enough to determine if it is the same device (logical, physical, virtual?), but also if the user has write access to both sections of the device. Getting a complete solution is really messy. For example, my employer has provided me with a Windows workstation with mounts to workgroup, departmental, and corporate Windows servers, plus a ClearCase mount to a Unix server, a mount to an IBM mainframe, and some mounts to sections of various SAN devices. We even have applications that add drive letters dynamically (X:, Y:) to its own servers (Linux on a virtual partition on the mainframe) while running, and remove them again afterwards. Not to mention that while you try hard to enumerate all the mount points, someone else could very well have copied, moved or deleted the file. :-) Bo Persson
On 12 July 2010 09:17, Daniel Trebbien <dtrebbien@gmail.com> wrote:
The basic idea is to have the ability to list mounted filesystems. I then suggested that `basic_path` could be extended with a new member (e.g.: `mount_path`) that will determine the mount path of the given path, and add a function to iterate over all mount paths.
I don't think that basic_path should have a member to get the mount path, because that's context-dependent. I feel that anything which looks at the filesystem should be in a non-member function. Can mount path be done more efficiently than just iterating through the known mount points? I can see value in some way to get the active mount points, though. I don't see any other doable function that could give the different root names on a system. ~ Scott
I don't think that basic_path should have a member to get the mount path, because that's context-dependent. I feel that anything which looks at the filesystem should be in a non-member function. Can mount path be done more efficiently than just iterating through the known mount points?
On Windows, I think that the `GetVolumePathName` function (http://msdn.microsoft.com/en-us/library/aa364996.aspx) can be used to obtain the mount path without iterating over all, current mount points. I don't know about Linux, though. Linux might be tricky because a running program might be `chroot`ed.
participants (6)
-
Andrey Semashev -
Bo Persson -
Daniel Trebbien -
Jeremy Maitin-Shepard -
Marius Stoica -
Scott McMurray