On 11 July 2010 15:50, Daniel Trebbien wrote:

Because the concept of drives is unique to Windows, Boost Filesystem does not implement such a function. Boost Filesystem and all Boost libraries are designed to be cross-platform.

Boost Filesystem paths do have the concept of a "root name", though, so it might be logical to have a function that lists them.

Boost Filesystem paths do have the concept of a "root name", though, so it might be logical to have a function that lists them. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Is it the same concept? Windows can "mount" something under a tree, or give it a drive letter, or both. That means you can list all roots that indicate mount points, regardless; or you can list all top-level roots that you need as starting points to traverse all files. The Windows function mentioned does the former. It includes roots that are reachable from another root, but indicate a transition to another file system. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

...

...

Boost Filesystem paths do have the concept of a "root name", though, so it might be logical to have a function that lists them.

Is it the same concept? Windows can "mount" something under a tree, or give it a drive letter, or both.

What if Windows only gives a drive a letter? Is this possible?

Trevor

I don't understand what you mean. After formatting a partition, I can make it available as a drive letter such as Q:. I can also make it available as a graft on an existing NTFS file system, such as C:\foo\media. Any number of either can exist at the same time for the same destination. Most HD partitions and plug-in drives exist for most people as drive letters only. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

No, my original comment was pointing out that the unix "roots" _are_ reachable from the top, as mount points. The Windows version of that function might list only those, or various other permutations.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Trevor Harmon Sent: Tuesday, July 13, 2010 3:25 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] list all drives

On Jul 12, 2010, at 5:13 PM, John Dlugosz wrote:

...

After formatting a partition, I can make it available as a drive letter such as Q:. I can also make it available as a graft on an existing NTFS file system, such as C:\foo\media.

Perhaps I misunderstood your earlier comments [1], but you seemed to be suggesting that a Boost facility for listing all roots is unnecessary because Windows drives can be mounted onto a single root.

But just because such a thing is possible doesn't matter. Is there ever a time that a file system is available only by drive letter -- that is, a separate and distinct root? If so, then a facility for listing all roots is still necessary in order to accommodate Windows.

Trevor

[1] http://lists.boost.org/boost-users/2010/07/60771.php

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

I'll bite, how about some functionality to list mounted filesystems or is that too OS specific.

Actually, that might work really well. I am not a Boost Filesystem developer, but it seems completely reasonable to me to extend `basic_path` with, say, a `mount_path` member, and add a function to iterate over all mount paths. Mount paths are cross-platform, right? I'm pretty sure. Looking at the list of currently-open Boost Filesystem tickets (https://svn.boost.org/trac/boost/query?status=%21closed&component=filesystem), it does not appear that there is a feature request for this, but maybe it has been discussed before. I will post a message to the Boost Developer's List to ask.

On Jul 12, 2010, at 8:21 AM, Michael Jackson wrote:

On 7/11/10 6:50 PM, in article AANLkTilxjfmegCAHrXnOKOPLPcDMXXabMgCLA9_FXH36@mail.gmail.com, "Daniel Trebbien" wrote:

...

...

Hi,

I am programming on a widows system. Is it possible to list all drives available in a system with boost::filesystem library or any other boost library?

I have gone through boost::filesystem documentation, but could not find any :(

Thanks a lot, Lloyd

Hi Lloyd,

Because the concept of drives is unique to Windows, Boost Filesystem does not implement such a function. Boost Filesystem and all Boost libraries are designed to be cross-platform.

To obtain a list of drives, you should instead use the Windows API function `GetLogicalDriveStrings`: http://msdn.microsoft.com/en-us/library/aa364975.aspx

Daniel

Doesn't OS X have the concept of separate Drives? They are all just mounted in /Volumes

Exactly. Mac OS X (like other unix-es) has a single-rooted file system; everything is under "/". (i.e, you can get to every file on the computer by starting at '/' and traversing the directory tree) Windows (AFAIK) does not - all the devices/drives are separate. -- Marshall

AMDG David Aldrich wrote:

I am linking my MSVC-9.0 project to the Boost.Python library. The project is configured to use the 'Multi-threaded DLL' runtime library.

When I link the project to Boost.Python, the linker evidently requires boost-python-vc90-mt-1_43.lib. But when I run the executable it loads boost-python-vc90-mt-1_43.dll.

Sorry if this is a stupid question, but why does the linker require the .lib file, when the runtime uses a dll?

boost-python-vc90-mt-1_43.lib is the import library for the dll. This is needed because you can't like directly to a dll on windows. In Christ, Steven Watanabe P.S. Please start a new thread instead of replying to an unrelated one.

When I link the project to Boost.Python, the linker evidently requires boost-python-vc90-mt-1_43.lib. But when I run the executable it loads boost-python-vc90-mt-1_43.dll.

Sorry if this is a stupid question, but why does the linker require the .lib file, when the runtime uses a dll?

It's just an import lib. Static libs begin with "libboost-".

On 7/12/10 11:31 AM, in article 967563BA-7178-42E5-8388-340DF5B26B58@gmail.com, "Marshall Clow" wrote:

On Jul 12, 2010, at 8:21 AM, Michael Jackson wrote:

...

On 7/11/10 6:50 PM, in article AANLkTilxjfmegCAHrXnOKOPLPcDMXXabMgCLA9_FXH36@mail.gmail.com, "Daniel Trebbien" wrote:

...

...

Hi,

I am programming on a widows system. Is it possible to list all drives available in a system with boost::filesystem library or any other boost library?

I have gone through boost::filesystem documentation, but could not find any :(

Thanks a lot, Lloyd

Hi Lloyd,

Because the concept of drives is unique to Windows, Boost Filesystem does not implement such a function. Boost Filesystem and all Boost libraries are designed to be cross-platform.

To obtain a list of drives, you should instead use the Windows API function `GetLogicalDriveStrings`: http://msdn.microsoft.com/en-us/library/aa364975.aspx

Daniel

Doesn't OS X have the concept of separate Drives? They are all just mounted in /Volumes

Exactly. Mac OS X (like other unix-es) has a single-rooted file system; everything is under "/". (i.e, you can get to every file on the computer by starting at '/' and traversing the directory tree)

Windows (AFAIK) does not - all the devices/drives are separate.

-- Marshall

Wouldn't "My Computer" on windows machines be analgous to the /Volumes on OS X? Therefor all drives are rooted at "My Computer"? Just a thought. Mike Jackson

Windows (AFAIK) does not - all the devices/drives are separate.

-- Marshall

Since you mentioned "AFAIK", I thought I'd fill in some more details. The Win32 API has separate roots, using letters and @. The underlying "native" OS uses a common root for named OS objects that includes files and many other things. The Win32 function you call takes care of qualifying names that are relative to a current directory and/or drive, and also takes care of drive letters, turning it into a full Native name. The drive letters are named symbolic links in a known place which seems to vary with Windows versions. In XP-64-bit, I see "\GLOBAL??" containing "A:" as a link to "\Device\Floppy0", etc. The "\Device" stuff is not accessible to Win32, but to drivers. It is like the Unix device directory, except it doesn't make it look like files in a file system. It's a tree of heterogeneous objects. Now, you can bypass the parsing done by Win32 and use a file name like "\\?\D:\foo\bar.txt". In other words, you _can_ start directly at the place where devices are specified. This same syntax is used for UNC names in the form "\\Server\share\...", so you can treat everything as a single root in windows where that root is "\\" and the local machine is "?\". This lets you specify devices with GUIDs as well as their assigned drive letters. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Are the native names that you are talking about canonical? Is there any way for a user-space program to obtain the native name for a drive or mounted folder (http://msdn.microsoft.com/en-us/library/aa364041.aspx)?

Using \\?\A:\foo is canonical. The real object locations in driverland have changed from version to version and the presence of Terminal Services. Many DDK functions work in user mode and can be called from ordinary programs, but I don't know off hand what does that translation. The resulting names only mean anything to Native calls anyway. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.