The documentation for os.path.normcase reads the case gets normalized
based on the file system
http://docs.python.org/dev/library/os.path.html

Current documentation:
Normalize the case of a pathname. On Unix, this returns the path
unchanged; on case-insensitive filesystems, it converts the path to
lowercase. On Windows, it also converts forward slashes to backward slashes.

Problem:
When mounting a network drive (via Samba) onto windows the mapped
network drive will claim to be an NTFS network (on Windows XP). Where
the network drive is actually a Samba share this can cause problems with
case sensitivity versus case insensitivity.

More:
The Windows based file systems such as FAT, FAT32 and NTFS are as a
matter of fact case preservant but case insensitive. That is a file
saved with the name 'MyName' will retain its name as 'MyName' and a ls
(dir) command will returnr the file as 'MyName' however access to
'Myname' or 'myname' or 'MYNAME' will all still access the same file.

Solution:
I suggest we drop converting the case to lower case where the file
systems FAT, FAT32 and NTFS are involved

To confirm this behaviour is still current:

Python 3.3.0a1+ (default:958a98bf924e+, May 21 2012, 22:18:16)
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ntpath
>>> ntpath.normcase(r"c:\mixedCASE")
'c:\\mixedcase'

In general, I'm not so sure of the use case of the function /at all/ - possibly something like
  
if normcase(path1) == normcase(path2):
    ...

however, this can give the false impression that two files are the same - I think, given a Samba share with two files 'A' and 'a', it's possible to access both files from windows.

OK, I did some quick tests. Given a samba share with the following files

A (contents: 'test: A')
a (contents: 'test: a')
B (contents: 'test: B')

1) opening \\share\files\A or \\share\files\a opens the same file - in my
case 'test: A'
2) opening \\share\files\B or \\share\files\b both work.

As such, the behaviour is at least not incorrect. In addition, it means
that the "if normcase(path1) == normcase(path2):" option to check if two
files are the same is actually correct (if normcase(path1) ==
normcase(path2) then open(path1).read() == open(path2).read() - at least on
the share I tested). Interestingly, os.path.samefile suggests this would
not be the case:

True
>>> os.path.samefile("u:\\a", "u:\\A")
False

On 22 May 2012 03:59, Ezio Melotti <report@bugs.python.org> wrote:

>
> Changes by Ezio Melotti <ezio.melotti@gmail.com>:
>
>
> ----------
> nosy: +brian.curtin, tim.golden
> stage:  -> needs patch
> versions:  -Python 3.4
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4198>
> _______________________________________
>

How does the new pathlib module handle this?  Also note from the docs for os.samefile() "Changed in version 3.4: Windows now uses the same implementation as all other platforms.".

When running a VirtualBox Windows 7 guest on Linux I have found that os.path.samefile() returns False when the filenames are the same, e.g.,

f = r'V:\pdfs\boson1.pdf'
same = os.path.samefile(f, f)
print(same) # expected True; got False

I mention it here because it may be part of the same problem.
I'm using Python 3.7.2.

> When running a VirtualBox Windows 7 guest on Linux I have found 
> that os.path.samefile() returns False when the filenames are the 
> same, e.g.,
>
> f = r'V:\pdfs\boson1.pdf'
> same = os.path.samefile(f, f)
> print(same) # expected True; got False

genericpath.samefile is unrelated to ntpath.normcase. It's based on comparing the st_dev and st_ino values from the os.stat result of each file. There are known problems with relying solely on the Windows implementation of os.stat for this. Please create a new issue to add your case to the list. Include details about the local volume or UNC share that's mounted as drive V:.

Filesystem paths in Windows are normally opened case insensitive, but a filesystem can choose to ignore this. NTFS does so for directories that flagged as case sensitive [1]. ntpath.normcase() doesn't incorporate this information. It would have to query the case-sensitive information for each component in the path. Instead it just assumes that all path components are case insensitive. That said, the way it does this does not correspond to how Windows filesystems implement case-insensitive comparisons. See bpo-42658. If supporting case-sensitive directories is needed, it should be addressed in that issue.

> same = os.path.samefile(f, f)
> print(same) # expected True; got False

I just followed up on investigating this. Apparently the VirtualBox "VBoxSharedFolderFS" filesystem generates a different file reference number randomly on each access. This violates the requirements for FileInternalInformation as specified in [MS-FSCC][2]. If file reference numbers aren't supported, the filesystem is supposed to return 0. That said, Python's samefile() doesn't currently follow the spec either. It blindly uses the st_dev (volume serial number) and st_ino (file reference number) values even when they're 0. See bpo-33935.

---

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_case_sensitive_information
[2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/7d796611-2fa5-41ac-8178-b6fea3a017b3