I'm not sure why this is, but ismount doesn't always work for me.  Itappears to fail on NTFS mounts.$ mount.../dev/sda1 on /media/windows type ntfs (ro,noexec,nosuid,nodev,user=ross)redbeard.local:/home on /media/home type nfs(rw,user=ross,noatime,rsize=65536,wsize=65536,retry=1,nfsvers=3,posix,intr,addr=192.168.1.67)$ pythonPython 2.4.5 (#2, Mar 12 2008, 00:15:51) [GCC 4.2.3 (Debian 4.2.3-2)] on linux2Type "help", "copyright", "credits" or "license" for more information.>>> ismount("/media/windows")False>>> ismount("/media/home")True

I cannot reproduce that; it works fine for me, with the same Pythonversion, on Linux 2.6.22.Can you please debug through ismount, and report which of the calls fail?The code of ismount readsdef ismount(path):    """Test whether a path is a mount point"""    try:        s1 = os.stat(path)        s2 = os.stat(join(path, '..'))    except os.error:        return False # It doesn't exist -- so not a mount point :-)    dev1 = s1.st_dev    dev2 = s2.st_dev    if dev1 != dev2:        return True     # path/.. on a different device as path    ino1 = s1.st_ino    ino2 = s2.st_ino    if ino1 == ino2:        return True     # path/.. is the same i-node as path    return False

Aha.  The contents of the mount point are only accessible by root:$ stat /media/windows/..stat: cannot stat `/media/windows/..': Permission deniedThis falls into the except block, so false is returned.If ismount() used os.path.dirname() instead of appending "..", then thiswouldn't happen.

> If ismount() used os.path.dirname() instead of appending "..", then this> wouldn't happen.But it may change the function result if the argument is a symlink tosomething (directory or mount point) on another filesystem. It should beverified before making a decision.

Another problem of using os.path.dirname is that for /A/B, it willreturn /A, and if /A is itself a symlink to a mount point itself, /A and/A/B will have different st_dev values... which will be wronglyinterpreted as meaning that /A/B is a mount point.So here is a possible course of action for ismount:1- first test if the arg is a symlink and if so, return False (as italready does today)2- then use os.path.realname(os.path.dirname(arg)) instead of joiningwith ".."

Confirm this problem exists in 2.7 as well.

I found another case where the result of ismount() is misleading. I'm using a FUSE-based filesystem controlled by a python supervisor daemon. When the fuse daemon dies and you try to access the filesystem with os.stat() it returns:OSError: [Errno 107] Transport endpoint is not connected: '/tmp/fuse-test'. Although, the filesystem is actually mounted and you can verify this:# cat /proc/self/mountinfo | grep fuse26 25 0:20 / /tmp/fuse-test rw,nosuid,nodev,relatime - fuse /dev/fuse rw,user_id=1000,group_id=1000,default_permissions,allow_otherIf the idea of ismount() is to show what paths are mountpoints, in this case it should return True, even if it's non-accessible (the fuse daemon died in this case, it might also happen for a stale NFS mount *not checked* ).

This bug is still present and annoying.For me it appeared when running ismount on a nfs-mounted directory, when the user who runs python has no read permission inside the directory. Therefore the lstat on /mntdir/.. fails.Attached a patch that fixes this by running abspath on the path.Symlinks will also work because they are checked/excluded before the part of the code where the patch is in.msg222528 is not related to the original bug and should be opened separately.

Is there any more info needed to the issue or the patch?It would be really helpful to have this fixed and I don't see any critical changes due to the patch. There is an issue in ansible depending on this fix:https://github.com/ansible/ansible-modules-core/issues/2186Also the current development version is affected (I manually checked 2.7, 3.0, 3.5, dev).

Thanks for the patch, Robin. The patch needs a test case. SeeLib/test/test_posixpath.py. The test coverage of ismount() is not high, so we need more tests. Also, I don't have much time to work on this right now, but Antoine's suggestion inmsg71294 sounds good to me. Did you try it?

Antoine's suggestion does not work, because "dirname" does not cover enough cases (for example trailing slash, possibly more).As suggested by him I now use realpath (instead of abspath). I can't come up with a symlink-situation that is broken with the old code, but realpath is what "ismount" actually means.I also added a testcase that resembles the issue, i.e. it fails with the old code and passes with the fix. I mock the "Permission denied" by raising a generic OSError. Mocking can not resemble every real-life situation but by simulating all issues reporting and then fixing them, one should get a solid test coverage. I also took the liberty of minor cleanup in/around the functions changed, i.e. remove unused imports and remove single-use variables to make the code easier to read.Attached the updated patch.

any comments/updates on merging this?

Any progress on merging this?The fix is simple, there is a test; anything else I can do to help?Ansible integrated the patch posted here as a workaround of an issue this caused. So there was some external review of the fix. Seehttps://github.com/ansible/ansible-modules-core/pull/2737

Based on the review by SilentGhost I removed all refactoring-changes and only left the one line needed for the fix.

What if use os.stat(dirname(path)) instead of os.lstat(parent)?-    if isinstance(path, bytes):-        parent = join(path, b'..')-    else:-        parent = join(path, '..')     try:-        s2 = os.lstat(parent)+        s2 = os.stat(dirname(path))     except OSError:         return False

Ah, forget, this doesn't work with path like "./.". Agreed, using realpath() is the simplest solution.

New changesetcbc78ca21977 by R David Murray in branch '3.5':#2466: ismount now recognizes mount points user can't access.https://hg.python.org/cpython/rev/cbc78ca21977New changesetdb9126139969 by R David Murray in branch 'default':Merge:#2466: ismount now recognizes mount points user can't access.https://hg.python.org/cpython/rev/db9126139969

Thanks, Robin.The patch doesn't apply on 2.7.  I'll leave this open to see if anyone wants to do the 2.7 port.

New changesetdd0f1fa809c5 by R David Murray in branch 'default':Rewrap long lines inMisc/NEWS.https://hg.python.org/cpython/rev/dd0f1fa809c5

David, issue2466_ismount_py2.7_port.patch does the py2.7 port. I also back port other ismount test cases not existing in py2.7.

New changeset75111791110b by R David Murray in branch '2.7':# 2466: ismount now recognizes mount points user can't access.https://hg.python.org/cpython/rev/75111791110b

Thanks, Xiang.

This is causing a test failure on the windows 8 bot.  Can you fix it Xiang?  Otherwise I'll have to revert.http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/870======================================================================ERROR: test_islink (test.test_posixpath.PosixPathTest)----------------------------------------------------------------------Traceback (most recent call last):  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_posixpath.py", line 110, in test_islink    os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2")AttributeError: 'module' object has no attribute 'symlink'======================================================================ERROR: test_ismount_symlinks (test.test_posixpath.PosixPathTest)----------------------------------------------------------------------Traceback (most recent call last):  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_posixpath.py", line 221, in test_ismount_symlinks    os.unlink(ABSTFN)WindowsError: [Error 2] The system cannot find the file specified: 'D:\\buildarea\\2.7.bolen-windows8\\build\\build\\test_python_2024/@test_2024_tmp'----------------------------------------------------------------------

Oh, sorry. Upload bot_failure_fix.patch to fix this.

New changeset63799c310b69 by R David Murray in branch '2.7':#2466: fix test failure on windows.https://hg.python.org/cpython/rev/63799c310b69

Thanks, Xiang.  Also thanks to SilentGhost, who noticed the buildbot failure I missed.