Boost logo

Boost :

Subject: Re: [boost] [Filesystem] Add features to list all mount paths, determine mount path of a path
From: Bo Persson (bop_at_[hidden])
Date: 2010-07-13 14:20:37

Andrey Semashev wrote:
> 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.

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

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