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

Preserving filename case #528

Closed
pwinckles opened this issue Mar 10, 2021 · 3 comments · Fixed by #641
Closed

Preserving filename case #528

pwinckles opened this issue Mar 10, 2021 · 3 comments · Fixed by #641
Assignees
Labels
Editorial Editorial issues (no changes to intent) OCFL Object Storage Root
Milestone

Comments

@pwinckles
Copy link

pwinckles commented Mar 10, 2021

The spec states:

File paths and filenames in the OCFL are case sensitive. Filesystems MUST preserve the case of OCFL filepaths and filenames.

What exactly does the second sentence mean? Does it mean that case must be preserved within the inventory? Does it mean that case must be preserved on the filesystem?

Regardless of the intent, it's not clear to me what an implementation is supposed to do on filesystems like NTFS and HFS. They will technically preserve case, but they are also case insensitive.

What is a client supposed to do if foo/bar.txt and Foo/Bar.txt are inserted into an object? My assumption is that OCFL wants them to be treated as distinct logical paths, but how do you translate them to content paths? A direct logical path to content path translation would result in an unintended collision. It would seem that using OCFL on case insensitive filesystems would require a more invasive translation.

Similarly, I learned this evening that HFS additionally NFD normalizes all filenames, which may cause issues for OCFL content paths.

@awoods
Copy link
Member

awoods commented Mar 10, 2021

I believe the context of the quoted statement (found in section 4.5 https://ocfl.io/1.0/spec/#filesystem-features) is a list of filesystem features that represent points of incompatibility with OCFL. I do not think there is anything "an implementation is supposed to do" beyond not using the filesystems or filesystem features mentioned in that list. In the case of filesystems that are case insensitive, they would not be recommended for use with OCFL.

@pwinckles
Copy link
Author

In the case of filesystems that are case insensitive, they would not be recommended for use with OCFL.

Interesting. In that case, it would seem that we should update the Fedora 6 documentation to indicate that Windows/Mac users should enable case-sensitivity. My understanding is that this is possible to some degree, though I have not seen it in person.

@zimeon
Copy link
Contributor

zimeon commented Sep 22, 2023

Editors' meeting 2023-09-22: We should change the second clause to point out that great care is required for OCFL implementations that use filesystems that do not preserve case or are not case sensitive

@rosy1280 rosy1280 removed the Implementation Notes Tickets to be included in implementation notes label Sep 22, 2023
@rosy1280 rosy1280 added this to the 2.0 milestone Sep 22, 2023
@zimeon zimeon added Editorial Editorial issues (no changes to intent) Storage Root OCFL Object labels Sep 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Editorial Editorial issues (no changes to intent) OCFL Object Storage Root
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants