Will file name case changes work when working solely with a non-case sensitive nodes such as Windows or HFS+ on a Mac? Assuming not but maybe using a an ext3 partition mounted with Ext2fs on Windows could make case changes work on Windows?
Likewise file name case changes seem to work great when working solely with Unix/ Linux systems.
Got a dose of what happens when mix case sensitive and non-case sensitive. Do not blame Syncthing for this. Do not know what solution there ever could be. Even if files were renamed with a three step process first changing to a unique name before changing case nodes that come online later wouldn’t work.
Figured out a solution that works reliably to change file case on Windows nodes without causing issues to the share. Utilize a “Send only” Unix node to push case changes to Windows node(s). Make sure no outstanding changes are on any Windows nodes in the cluster before overwriting or else these will be overwritten.
Yeah, that should work. The other way to reliably do a case only rename between case insensitive systems is to go via a file name that differs in more than just care, i.e., a two step operation.
Further than the problem of the case handling between win and linux, isn’t there a max file name length problem too ?
I not sure because I don’t use windows enough anymore, and I know nothing about Mac.
Have found that multi step rename process to bypass Windows case rename does not work well if all nodes are not online at time of change. If an offline Windows node comes online after a two step case name change from demo to demo2 to DEMO all it seems to want to do is try to rename it’s current demo to DEMO which isn’t possible. Hope this makes sense.
I have a few headless Linux VMs in various offices mounting local CIFS and syncing them.
I found schnappi’s solution by chance as well: demo --> DEMO1 --> DEMO
Wait a minute or 2 for sync to propagate changes before making the next change.
What if syncthing does that by itself? When a rename is detected compare uppercase versions of both names and if they are the same issue two remame commands with some temporary name for the first one?
Am not sure if this is what actually happens or not so someone else may need to chime in. Do not think that automatically using a two step process to rename would make any difference. Here is why.
Imagine three nodes. Two nodes are online. A file/ folder gets changed from demo to demo1 to DEMO either through an automated process or manually. When the third node comes online it still only “sees” a change of demo to DEMO.
Yeah, this manually renaming thing is a pain (you know where).
It just don’t work with syncthing, if you have more than 2 devices.
If you have Linux-, a Mac- and a Windows-Devices where their syncfolders are set up to Send&Receive, you are totally lost if a windows user changes the case of a filename.
I have spend hours trying to find a best way to fix out-of-sync-issues, because of filename-case-changes. And I have given up.
Edit:
Ok, an examples:
A Windows user creates a file named “foo.txt”.
“foo.txt” is synced from the Windows client to a Linux client.
The Windows user then renames the File “foo.txt” to “Foo.txt”.
“Foo.txt” is synced from the Windows Client to a Linux client. (Syncthing creates a new file on the Linux Client, because the Linux filesystem allows Upper-/Lowercase filenames in the same folder and “Foo.txt” did not exist before on the Linux client. That way syncthing cannot check if the new file could be a filerename from the windows side…)
Now, on the Linux client two files “foo.txt” and “Foo.txt” exist.
When the Linux client tries to sync those files back, windows filesystem has a problem, because it doesn’t allow “Foo.txt” and “foo.txt” at the same time in the same folder.
Now, imagine a addidtional Mac OSX with filesystem HFS in the syncthing cluster and now it goes all around with the doublettes and new filenames, etc…
Don’t give up. A send-only master node on a Unix system will solve the issue.
This isn’t Syncthing’s fault. Windows and Mac with HFS being case aware but not case sensitive is the issue. The only reason Dropbox or any other service may work for case change is because an always on master server receives changes from all nodes and then pushes changes to other devices. Which is (almost) exactly what a send only Syncthing node can do.
All this being said do not even think alternatives to Syncthing will work perfectly for case changes. Google utilizes a custom file system and think part of the reason they did this is to somehow deal with case changes with Google Drive and Windows.
At least, I never had those problems with DropBox. I’m using a client for all the mentioned OSses. But thats not the point here.
My point/wish is, that syncthing could check “better/harder/with more love” if an existing file could be renamed.
I guess, syncthing always creates a new file on other clients when a local file is renamed, because there is no 1:1 relation for each sync’ed folder.
I just wish, syncthing would check, weather a same file (metadata/indexes?) already exists on a remote folder and therefore just rename it, and not create a new one with a different case, which (we all know) will just irritate the OS and the users
For my technical understanding, it could be something like: make a CRC of the file to be transfered and check with the CRC of the file to be created/overwritten/deleted on the remote system. If the CRC match and the foldernames match and some metadata as well, then syncthing can be 99% sure, its just a renaming. At least, no data will be harmed, because nothing will be deleted. Just renamed. If nothing matches, syncthing then just creates a new file…
Syncthing does versionising, so there must be some kind of “memory” for files…
But hey, I never took a look (ok, just quick one) at the sources…I’m just nagging…
Btw:
The linux send-only master, you mentioned, will avoid linux users to get updated files/folders from the mac or windows clients. So that’ll not work here. Unless, I do not know or see what you do
Your right. A Linux send only node cannot receive changes. However a Linux send only node could temporarily (then send only could be turned on) be used when all nodes are online to change file/ folder case(s) on Windows nodes. A two step rename could do the same thing with all nodes online too though. All a send only node really does is allow a case change without all nodes being online at the same time at the expense of not being able to add files to any other node until all nodes do come online again.
Despite how convoluted that is still cannot think of a better solution to change case. If Syncthing implemented a system to check if folders with different case are the same how would that effect case sensitive file systems where users want two identical folders with the same name in different cases? Granted that likely rarely occurs but any such case change system may have unintended consequences on case sensitive operating systems. Completely agree (almost) no one is going to do this but believe a solution to any problem uniformly handles any variable of a given situation. Still it would be neat if someone could figure it out.
My guess is that there is a 1:1 relationship between files and that on Windows Syncthing uses the initial case for a file/ folder.
Believe file “memory” consists solely of deleted files to prevent from being brought back from a long offline node as it was explained to me. Fairly certain versioning just moves files to the .stversions folder instead of removing and lacks any “memory” about what it is doing.
If we could come up with a specific and realistic suggestion on how to implement seamless case changes feel like it would be seriously considered, written, and likely implemented if it was possible.
Do you have other ideas on how case changes on Windows could be implemented that also addresses case sensitive file systems being able to have identical folders with different cases?
A solution for case sensitivity on Windows is to run Syncthing in the Windows Subsystem for Linux. Windows Subsystem for Linux recognizes case (https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/). Theoretically it appears possible to recognize case sensitivity (and just run Syncthing on Windows) in select folders outside of the Windows Subsystem for Linux using: fsutil.exe file setCaseSensitiveInfo <path> enable
but to keep it simple (above isn’t recursive) just use the file location relative to the Windows Subsystem for Linux for adding Syncthing folders and run Syncthing in the Windows Subsystem for Linux.
C:\Users\%USERNAME%\AppData\Local\Packages\DEBIAN OR CHOSEN DISTRIBUTION REALTED FOLDER NAME\LocalState\rootfs\home\USER
Microsoft recommends not to edit files here directly but one can. This is probably recommended so that that a system folder doesn’t get deleted accidentally.
A few notes. Open the Windows firewall manually (will not get prompt). Don’t worry about iptables or any firewall on the Windows Subsystem for Linux. When adding folders in Syncthing use location relative to the Windows Subsystem for Linux ("~/Whatever Folder" or /home/USER/Whatever folder).
/home/USER/Demo or ~/Demo
corresponds to
C:\Users\%USERNAME%\AppData\Local\Packages\DEBIAN OR CHOSEN DISTRIBUTION REALTED FOLDER NAME\LocalState\rootfs\home\USER\Demo
Finally Windows Subsystem for Linux currently cannot run in the background. A bash shell must always stay open. Got a hidden bash shell running but not worth it. Windows 10 build 17046 will enable one to run Syncthing (or anything else) and then close the bash Window (https://blogs.msdn.microsoft.com/commandline/2017/12/04/background-task-support-in-wsl/). Windows 10 build 17046 is currently available as Windows Insider Build and will be released as part of the Windows 10 Spring Creators Update which will be released soon. For now just leave the bash Window minimized for a month or so if using this method.
Here is the Windows task scheduler command that can be used to autostart Syncthing (once the bash shell is running and assuming running Debian with Syncthing installed as Debian package).
To anyone who wants case sensitivity that much with Syncthing on Windows but is nervous about running the Windows Subsystem for Linux you can absolutely figure it out. People here would help through process if needed.
