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

Pick how to handle conflicts in filesystem case sensitivity or insensitivity #8

Open
ferd opened this issue Jan 27, 2019 · 3 comments

Comments

@ferd
Copy link
Owner

ferd commented Jan 27, 2019

OSX is, by default, case insensitive.
So is Windows under NTFS and FAT32.
So is ExFAT.

Linux and BSD filesystems (ext3/4, UFS) are case sensitive.

ZFS is configurable.

A decision is required on how to handle these and make them work.

@ferd
Copy link
Owner Author

ferd commented Jan 27, 2019

What DropBox does:

Case insensitivity

Like Dropbox itself, the Dropbox API is case-insensitive, meaning that /A/B/c.txt is the same file as /a/b/C.txt and is the same file as /a/B/c.txt.

This can cause problems for apps that store file metadata from users in case-sensitive databases (such as SQLite or Postgres). Case insensitive collations should be used when storing Dropbox metadata in such databases. Alternatively, developers need to make sure their query operators are explicitly case insensitive.

Also, while Dropbox is case-insensitive, it makes efforts to be case-preserving. Metadata.name will contain the correct case. Metadata.path_display usually will contain the correct case, but sometimes only in the last path component. If your app needs the correct case for all components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry.

From https://www.dropbox.com/developers/documentation/http/documentation

@llelf
Copy link

llelf commented Feb 16, 2019

Also: Unicode normalization.
Examples:

  • HFS+ normalizes (NFD) on write;
  • APFS compares under normalization;
  • ZFS configurable

@ferd
Copy link
Owner Author

ferd commented Feb 17, 2019

yeah. I've just updated the model I'm using for tests to deal with case sensitivity and to use normalization there, it would be rather simpler to add a form of normalization there to force all tests to work with them.

So far I'm thinking of internally being case insensitive with ~250 chars limit (windows-like); If better solutions appear later, it's simpler to relax rules than constrain them. The big question is more about at which level should the detection of conflict be done (on-scan and on-sync, but lowest or higher processing layers?), and how to notify the user about it. So far there's nothing existing so there's no clear case of how to do things.

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

No branches or pull requests

2 participants