Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File name case sensitivity issues in the Windows system #2646

Closed
lidanqing123 opened this issue Jan 9, 2024 · 8 comments
Closed

File name case sensitivity issues in the Windows system #2646

lidanqing123 opened this issue Jan 9, 2024 · 8 comments
Assignees
Labels
enhancement An improvement rather than a bug excellent_report
Milestone

Comments

@lidanqing123
Copy link

lidanqing123 commented Jan 9, 2024

I developing on Windows. This error may be due to the fact that I have set up my Windows system's environment.

fsutil file setCaseSensitiveInfo path enable

This is because when using Git, I often run into file or directory name case conflicts.

I'd suggest that nuitka could change os.path.normcase to os.path.normpath

Originally posted by @lidanqing123 in #2645 (comment)

@lidanqing123
Copy link
Author

图片

@lidanqing123 lidanqing123 changed the title Sensitivity to the case of Chinese file names on Windows File name case sensitivity issues in the Windows system Jan 9, 2024
@lidanqing123
Copy link
Author

@kayhayen
Copy link
Member

kayhayen commented Jan 9, 2024

I removed one use of it the other day, where it checks for .ico suffix, simply because it is code duplication with hasFileExtension but I guess, that one does it too.

@kayhayen kayhayen added the enhancement An improvement rather than a bug label Jan 9, 2024
@kayhayen
Copy link
Member

kayhayen commented Jan 9, 2024

Using os.path.normpath does not allow for case insensitive approaches, so Python doesn't support it. I only tried with 3.10, but that what matters. So it seems we need our own function. The below code illustrates the main use of it. A new function that takes your setting into account is definitely doable, lets see if we find something existing.

def areSamePaths(path1, path2):
    """Decide if two paths the same.

    Args:
        path1: First path
        path2: Second path

    Returns:
        Boolean value indicating if the two paths point to the
        same path.

    Notes:

        Case differences ignored on platforms where that is the
        norm, and with it normalized, and turned absolute paths, and
        even short paths, it then becomes a mere string compare after that.
    """

    path1 = os.path.abspath(os.path.normpath(path1))
    path2 = os.path.abspath(os.path.normpath(path2))

    if os.path.exists(path1) and os.path.exists(path2):
        path1 = getExternalUsePath(path1)
        path2 = getExternalUsePath(path2)

    path1 = os.path.normcase(path1)
    path2 = os.path.normcase(path2)

    return path1 == path2

@kayhayen kayhayen self-assigned this Jan 9, 2024
@kayhayen kayhayen added this to the 2.0 milestone Jan 9, 2024
@kayhayen
Copy link
Member

kayhayen commented Jan 9, 2024

I have replaced uses of assignments from os.path.normcase that then can cause these filenames to be wrong, there were a few more things like that, and the code could be done better in all cases by using APIs that compare without modifying.

Generally it cannot be avoided. Comparisons cannot be made real, i.e. it's virtually impossible to detect if a folder has this attribute set in Python. The C API for that is very ugly, and even then, it's very unclear when it must be done or not, e.g. when searching for a module, when it's filename based and wrong in Python or not.

But I believe it might work better for you now.

@kayhayen
Copy link
Member

kayhayen commented Jan 9, 2024

Thanks for your report, this is fixed on the factory branch, which is a development version under rapid development. You can try it out by going here: https://nuitka.net/doc/factory.html

Feedback if this is working is very welcome, just please do not share plans of doing it, but rather confirmations or denials of it working.

@kayhayen kayhayen added factory For issues fixed in factory only excellent_report labels Jan 9, 2024
@kayhayen
Copy link
Member

These changes are now on develop, let me know if it works for you now.

@kayhayen kayhayen added develop For issues fixed in develop only and removed factory For issues fixed in factory only labels Jan 12, 2024
@kayhayen
Copy link
Member

This is part of the stable release 2.0 that I just made.

@kayhayen kayhayen removed the develop For issues fixed in develop only label Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An improvement rather than a bug excellent_report
Projects
None yet
Development

No branches or pull requests

2 participants