Thank you @imsodin for the fast response.
The one thing that the documentation doesn’t explicitly state is what happens if a file is renamed to change the case. I recall reading about potential conflicts there. Perhaps I am misunderstanding the behaviour in some way. Perhaps the case change is simply ignored instead of being synchronized?
In addition, I would say that, in my opinion, it incorrectly states that this issue is specific to operating systems, however, Linux can have both FAT type file systems and the NTFS file system, all of which are treated as case insensitive by Linux in my limited experience. And like I mentioned, while likely not common, Windows can now support case-sensitive folders, which was most likely done for WSL, but can be used for other things.
If you, or anyone, can provide clarity on that, I would greatly appreciate it.
Everything just happens as if the filesystem was case sensitive, as long as there’s no case conflict. If there is, there will be a a sync error (failed items in the web UI) indicating there’s a case conflict. So changing the case of a file just does that, without a problem, regardless of os/filesystem.
The statement is purposefully vague, and could possibly be made even more vague (just “Some systems”) - the cause can be anything from OS, to filesystem, to some weird layer between filesystem and user applications like Syncthing - it doesn’t really matter.
In regards to a case change I was thinking (which I believe someone previously mentioned) what if the case is changed at one client, and the actual file is modified at another, both occurring before the sync happens. It sounds like you are saying a case change will be considered as a sync error and thus essentially not supported. I am most likely misunderstanding this.
Being vague in that case makes sense to me, however that page specifically says “Some operating systems (e.g. Windows, Mac and Android to an extent) assume the opposite”, not just “system”. https://docs.syncthing.net/users/syncing.html#case-sensitivity
Perhaps it would be better to say something like “Some file systems (e.g. FAT, vFAT, FAT32, NTFS) are treated by their operating system to assume the opposite unless some layer overrides that”. I would say that this statement applies to Linux as well, although those file systems are not often used there.
I apologize if I seem to be a pain about this. I’m not intending that.
I do appreciate you trying to help me obtain full clarity on this.
Feel free to improve the docs - generally any help on docs is much appreciated!
So we have file foo and devices A and B which have a case-insensitive system. Now A edits foo, and B renames it to Foo. Then most likely you’ll get sync errors on both sides (maybe it will also resolve fine on one side, and only the other gets the error - depends on specifics), saying something like “the case on disk foo differs from the filename Foo”, or vice-versa. The whole problem only comes up because there’s essentially a conflict/race here. Otherwise things just work.
In general, I am very uneasy to attempt to update the docs when I feel that my knowledge of the application is extremely limited. In this specific case, it is not so bad, however, I can see someone else essentially not like if someone who doesn’t understand or contribute to the app attempts to make changes to the documentation.
I’ll have to think about what I would actually suggest the change to be. My previous suggestion was just a quick thought I had that I hoped could potentially spark ideas in others and possibly lead to an eventual improvement.
When you submit a pull request it is checked over by one of the project leads before the changes take effect. This gives them the chance to check that you haven’t made any mistakes and that the contribution is suitable. You can always submit your suggestions here on the forum beforehand
The fact that your knowledge is limited is actually a real benefit in some cases - us old hands have years of experience of the software and may not realise that the documentation is missing certain steps or explanations. To us, we learned it ages ago and need to be reminded of the point of view of newcomers.
I completely understand what you are saying there, being a software engineer myself. It is always a difficult thing to not get one’s self trapped in the ways we are used to doing things, and how we communicate. Being trapped like that makes it difficult to see issues others experience and to communicate with them in a way they can understand.
A note in case someone else reads this in the future.
I have since gained a bit of a better understanding on Linux’s behaviour with NTFS.
While it is often used as a case insensitive file system, Linux doesn’t completely treat it that way. If you ask it to access “FileX”, but the name is “filex”, depending on how it is done (the calls and code used), the file may not be found. This is different from Windows where it knows that the file system (at least in the specific folder) is case insensitive and therefore it treats it that way.
Note that while I still do not have a full understanding of the inner workings there, I thought this note was a worthwhile addition to try to eliminate or reduce the possible confusion or misleading of people.
