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

Examine possible issues with case-insensitive file systems #13

Open
Sipkab opened this issue Feb 25, 2020 · 1 comment
Open

Examine possible issues with case-insensitive file systems #13

Sipkab opened this issue Feb 25, 2020 · 1 comment

Comments

@Sipkab
Copy link
Member

Sipkab commented Feb 25, 2020

Saker.build primarily uses case-sensitive representation of files and their hierarchies. This may cause some synchronization or other file management issues when dealing with case-insensitive file systems.

In general, we expect developers to use proper casing when referencing files. That is, they should reference the files in a case-sensitive way in case-insensitive file systems as well. It is an acceptable error if there is a case-insensitive file conflict during build.

However, there may be issues when the developers change the capitalization of files, therefore triggering build tasks and various other file related operations. (E.g. synchronization) These effects and possible scenarios should be examined as part of this issue.

@Sipkab
Copy link
Member Author

Sipkab commented May 11, 2020

This issue is predominantly relevant on Windows as that uses case-insensitive file system by default while Linux and macOS uses case sensitive.

One issue is when a file gets renamed:
Run a task for some file, file.txt
Rename it to FILE.txt.
The changes are not detected properly. This is due to the fact that the build system still can open FILE.txt with a path named file.txt.

We could solve this issue somehow by using the GetFinalPathNameByHandle function when dealing with files.
Once a file is opened, we get the actual path, and compare its capitalization. If matches, we proceed with the call, if not, we throw an exception.
We need to also handle opening files with different capitalization. The symbolic link handling also needs to be tested.

This requires a native library to be added for Windows. We would also need to reimplement the InputStreams for the opened files so we can avoid opening a file twice.

Additionally, file renaming and name examination should be tested using GetFileInformationByHandle and related functions. (renaming, file name retrieval)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant