You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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
The spec states:
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
andFoo/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.
The text was updated successfully, but these errors were encountered: