This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.path.ismount on windows doesn't support windows mount points
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: tim.golden Nosy List: Christian.Tismer, Oren_Held, brian.curtin, giampaolo.rodola, ishimoto, markm, orsenthil, python-dev, santoso.wijaya, sijinjoseph, tim.golden
Priority: normal Keywords: patch

Created on 2010-06-20 08:49 by Oren_Held, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue9035.patch ishimoto, 2012-07-29 02:24 review
issue9035.4.patch tim.golden, 2013-07-31 08:26 review
Messages (21)
msg108225 - (view) Author: Oren Held (Oren_Held) Date: 2010-06-20 08:49
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..
msg108230 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2010-06-20 09:11
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?
msg108231 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2010-06-20 09:55
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.
msg108232 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2010-06-20 10:04
... 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.
msg108361 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-06-22 10:46
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).
msg108363 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2010-06-22 10:56
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
msg134434 - (view) Author: Sijin Joseph (sijinjoseph) Date: 2011-04-26 00:26
I'd like to add the win_ismount function mentioned by Tim. Is anyone else working on this presently?
msg134670 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2011-04-28 11:56
Sijin, please go ahead and submit a patch. No one is working on this at the moment.
msg138197 - (view) Author: Mark Mc Mahon (markm) * Date: 2011-06-12 03:23
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)
msg144895 - (view) Author: Oren Held (Oren_Held) Date: 2011-10-04 15:30
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
msg144896 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-10-04 15:33
We can't depend on stuff from pywin32, but we could expose GetVolumePathName ourselves.
msg166703 - (view) Author: Atsuo Ishimoto (ishimoto) * Date: 2012-07-29 02:24
Patch to expose GetVolumePathName() and implementation of ismount().
Tested on Windows7/XP.
msg171467 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2012-09-28 13:57
Unfortunately this missed the boat for 3.3; I'll target 3.4 when we've got a branch to commit to.
msg193562 - (view) Author: Christian Tismer (Christian.Tismer) * (Python committer) Date: 2013-07-22 19:31
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
msg193932 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-07-30 13:15
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.
msg193939 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-07-30 16:14
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.
msg193958 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-07-30 21:36
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.
msg193989 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-07-31 08:26
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.
msg194049 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-08-01 11:45
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
msg194065 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-08-01 13:03
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
msg194077 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-08-01 15:02
Fixed. Thanks for the patch
History
Date User Action Args
2022-04-11 14:57:02adminsetgithub: 53281
2013-08-01 15:02:40tim.goldensetstatus: open -> closed
resolution: fixed
messages: + msg194077

stage: needs patch -> resolved
2013-08-01 13:03:35python-devsetmessages: + msg194065
2013-08-01 11:45:54python-devsetnosy: + python-dev
messages: + msg194049
2013-07-31 08:26:39tim.goldensetfiles: - issue9035.3.patch
2013-07-31 08:26:33tim.goldensetfiles: - issue9035.2.patch
2013-07-31 08:26:22tim.goldensetfiles: + issue9035.4.patch

messages: + msg193989
2013-07-30 21:36:49tim.goldensetfiles: + issue9035.3.patch

messages: + msg193958
2013-07-30 16:14:47tim.goldensetfiles: + issue9035.2.patch

messages: + msg193939
2013-07-30 13:15:29tim.goldensetmessages: + msg193932
2013-07-22 19:31:45Christian.Tismersetnosy: + Christian.Tismer
messages: + msg193562
2012-09-28 13:57:27tim.goldensetmessages: + msg171467
versions: + Python 3.4, - Python 3.2, Python 3.3
2012-07-29 02:24:13ishimotosetfiles: + issue9035.patch
keywords: + patch
messages: + msg166703
2012-07-28 02:09:50ishimotosetnosy: + ishimoto
2011-10-04 15:33:30brian.curtinsetmessages: + msg144896
2011-10-04 15:30:12Oren_Heldsetmessages: + msg144895
2011-06-12 03:25:36brian.curtinsetnosy: + brian.curtin
2011-06-12 03:23:50markmsetmessages: + msg138197
2011-04-28 11:56:08orsenthilsetnosy: + markm
messages: + msg134670
2011-04-26 00:36:51santoso.wijayasetnosy: + santoso.wijaya

versions: + Python 3.3
2011-04-26 00:26:44sijinjosephsetmessages: + msg134434
2011-04-25 22:04:14sijinjosephsetnosy: + sijinjoseph
2010-06-22 10:56:12tim.goldensetmessages: + msg108363
2010-06-22 10:46:44orsenthilsetnosy: + orsenthil
messages: + msg108361
2010-06-20 14:19:04giampaolo.rodolasetnosy: + giampaolo.rodola
2010-06-20 10:04:51tim.goldensetmessages: + msg108232
2010-06-20 09:55:52tim.goldensetmessages: + msg108231
title: os.path.ismount on windows doesn't support windows mount points -> os.path.ismount on windows doesn't support windows mount points
2010-06-20 09:11:49tim.goldensetassignee: tim.golden
type: behavior
versions: + Python 3.2, - Python 2.6, Python 2.7
nosy: + tim.golden

messages: + msg108230
stage: needs patch
2010-06-20 08:49:10Oren_Heldcreate