On unices, ismount checks whether the given path is a mount point.
On windows, it only checks whether it's a drive letter.

Long story short, Python simply returns False when doing ismount(r"c:\mount1"), while c:\mount1 is a real mount point.

This is relevant for all modern windows versions.

-- 

I'm using win32file.GetVolumePathName() for overcoming this, but I'm not sure if the os python package should be importing win32file, maybe there is a better way to check whether a path is a mount point..

Switching to Python 3.2 as this essentially constitutes a behaviour change and 2.6 is in bugfix mode and 2.7 is about to enter rc2. It would certainly be possible to use one of the volume APIs under the covers. Would you be willing to offer a patch to, say, posixmodule.c?

All we need to do is check the FILE_ATTRIBUTE_REPARSE_POINT
in the file attributes. Frustratingly, we grab file attributes
a dozen times in posixpath.c only to throw most of it away.

Is there a case for adding an "attributes" function to os.path
which exposes the full file attributes on Windows, and its
posix equivalent if there is one? This could then be used
in the ismount function currently implemented in ntpath.py.

... of course you still need to get the reparse tag to determine whether this is a mount point so the file attributes alone in this case are not enough.

I see that ismount like function on windows is provide by the various
Win32 extensions. 

If Windows supported is added to ismount function itself, then it might be
a good idea to have attributes or list_attributes function as well.

But for posix, how will it be different from details provided by stat?
Would not it add redundancy?

Or would it be better to provide file attributes as part of stat
itself (if some are missing in Windows).

I think we're saying the same thing :)

The simplest thing to do here is to create a win_ismount function
in posixmodule.c which does the attributes / reparse tag dance and
returns True/False and use that wherever it's needed to support this
concept under Windows. The current solution is correct for a subset
of cases. Arguably a bug, although I doubt I'd get that past the
release manager!

The wider issue of exposing GetFileAttributesW, eg under one of the
unused stat fields, should be explored elsewhere.

On 22/06/2010 11:46, Senthil Kumaran wrote:
>
> Senthil Kumaran<orsenthil@gmail.com>  added the comment:
>
> I see that ismount like function on windows is provide by the various
> Win32 extensions.
>
> If Windows supported is added to ismount function itself, then it might be
> a good idea to have attributes or list_attributes function as well.
>
> But for posix, how will it be different from details provided by stat?
> Would not it add redundancy?
>
> Or would it be better to provide file attributes as part of stat
> itself (if some are missing in Windows).
>
> ----------
> nosy: +orsenthil
>
> _______________________________________
> Python tracker<report@bugs.python.org>
> <http://bugs.python.org/issue9035>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk

I'd like to add the win_ismount function mentioned by Tim. Is anyone else working on this presently?

Sijin, please go ahead and submit a patch. No one is working on this at the moment.

I was looking at this - and see that (at least as far as GetFileAttributes is concerned) that a mount and a linked directory are seen the same...

Here are some tests using ctypes

# mounted drive
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\test_c_mount"))
'0x410'

# normal directory
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\orig"))
'0x10'

# link (created via mklink /d c:\temp\orig c:\temp\here2
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\here2"))
'0x410'

On futher searching - I found the following link:
http://msdn.microsoft.com/en-us/library/aa363940%28v=vs.85%29.aspx

So the function ismount will need to do the following
a) Get the file attributes
b) check that it's a directory and is a reparse point
c) Use FindFirstFile (and FindNextFile? - I need to test more) to fill in WIN32_FIND_DATA.dwResearved0
d) Check that against IO_REPARSE_TAG_MOUNT_POINT (0xA0000003)

Anything wrong with the following simple approach? (e.g. is it bad to depend on win32file?)

def win_ismount(path):
  import win32file
  volume_path = win32file.GetVolumePathName(path)
  return volume_path == path # May have to ignore a trailing backslash

We can't depend on stuff from pywin32, but we could expose GetVolumePathName ourselves.

Patch to expose GetVolumePathName() and implementation of ismount().
Tested on Windows7/XP.

Unfortunately this missed the boat for 3.3; I'll target 3.4 when we've got a branch to commit to.

Hi Tim,

Yes, this would be great to get sorted out.
Then we could make watchdog.py automatically
configure itself for network mounts.

Right now this makes no nense because of windows.

cheers - chris

I put a bit of work in on this this morning, following Mark's suggestion (msg138197) since that's the "canonical" approach. Unfortunately, it completely fails to work for the most common case: the root folder of a drive! The documentation for FindFirstFile explicitly precludes that possibility.

It looks as though  GetVolumePathName is the way to go. I thought I'd previously found some instance where that failed but, ad hoc, I can't make it fail now. I'll try to rework Atsuo's patch against the current posixmodule.c.

issue9035.2.patch is an updated version of Atsuo's patch. 

Known issues:

* I haven't reworked it for the new memory-management API
* There's no test for a non-root mount point (which is really the basis for this issue). It's difficult to see how to do that in a robust way on an arbitrary machine without quite a bit of support machinery. I've done ad hoc tests which succeed.

issue9035.3.patch has switched to the new memory management API and has 
tweaked the tests slightly for robustness.

This approach does introduce a behavioural change: the root of a SUBSTed 
drive (essentially a symlink into the Dos namespace) will raise an 
OSError because GetVolumePathName returns error 87: invalid parameter. 
So os.path.ismount("F:\\") will fail where F: is the result of running, 
eg, "SUBST F: C:\temp".

I think the simplest thing is to special-case drive roots (which are 
always mount points) and then to apply the new GetVolumePathName logic.

4th and hopefully final patch. Added tests for byte paths. Reworked the ismount so it uses the original detection approach first (which is wholly lexical) and drops back to the volume path technique only if the path doesn't appear to be a drive or a share root. This should minimise backwards-incompatibility while still solving the original problem.

New changeset f283589cb71e by Tim Golden in branch 'default':
Issue #9035: os.path.ismount now recognises volumes mounted below
http://hg.python.org/cpython/rev/f283589cb71e

New changeset 5258c4399f2e by Tim Golden in branch 'default':
issue9035: Prevent Windows-specific tests from running on non-Windows platforms
http://hg.python.org/cpython/rev/5258c4399f2e

Fixed. Thanks for the patch