Capital letters in filenames


(Alexey T) #1

I have two machines on Windows with a sync folder

Machine A: sync\aaa.txt

Machine B: sync\Aaa.txt

Syncthing do not sync such files.


(usernamegoeshere) #2

windows (a.k.a. ntfs/fat/fat32/exfat) doesnt differentiate between cases. its all the same file it it. but if you have two different files the aaa.txt one one machine1 with content-a, and the Aaa.txt file on machine2 with content-b, then its a conflict, it will never sync those files. for windows the filenames are the same, but the hashed content is differing, wonder what syncthing makes of this situation. maybe the newer file will fire and win the situation. never thought about this case.


(Alexey T) #3

File contents are identical


(usernamegoeshere) #4

What does the syncthing log show for this situation? How about renaming the files on both ends to a unified style if possible?


(Alexey T) #5

Log says: Folder “folder” isn’t making progress, pausing puller for 1m


(Simon) #6

It’s a bit worse than that: Syncthing does differentiate filenames by case, which can even break stuff. However if you only use windows, how did you manage to create those two files? That should not be possible in the first place. In any case the solution is to get rid of one of the files whose names only differ by case.


(Jakob Borg) #7

I read it as the files being on two different machines and having the same contents, which as far as Syncthing is concerned means they are in sync.

The error is probably something else. Logs, or click the “Failed items” in the GUI. Speculating without data is pointless.


(Alexey T) #8

Syncthing doesn’t show failed items. The folder is out of sync with some out of sync items. Log endelssly says [K2KRE] 14:52:23 INFO: Folder “SyncThing” (SyncThing) isn’t making progress. Pau sing puller for 1m0s.

I have two files in my folder:

ptirerix.jpg

~syncthing~PtiRerix.jpg.tmp


(Alexey T) #9

Windows allows to name files and folders using all letter cases


(Simon) #10

Ah right, I didn’t read the original post well enough.

@Xeenych Which version do you use? If you are on v0.14.40 there should be a line like this in the logs before every “isn’t making progress” line:

[K2KRE] 14:52:23 INFO: Puller (folder "SyncThing", file "file/that/makes/problems"): context to the problem: error message

If you are on 0.14.39, update or set STTRACE=model env variable.


(Alexey T) #11

Hope this is the needed part.

The failed item is ptirerix3.jpg

[K2KRE] 2017/11/09 15:17:16.530422 rwfolder.go:1070: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 need file 1986 - 1988 - крахмальный-ЦТШ\Кроки+текст\ptirerix3.jpg; copy 0, reused 4
[K2KRE] 2017/11/09 15:17:16.531422 progressemitter.go:211: DEBUG: progress emitter: registering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+тек
ст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.531422 rwfolder.go:1154: DEBUG: not weak hashing 1986 - 1988 - крахмальный-ЦТШ\Кроки+текст\ptirerix3.jpg. file did no
t contain any weak hashes
[K2KRE] 2017/11/09 15:17:16.545422 rwfolder.go:1435: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 closing 1986 - 1988 - крахмальный-ЦТШ\Кроки+
текст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.545422 rwfolder.go:1367: DEBUG: file modified but not rescanned; not finishing:
[K2KRE] 2017/11/09 15:17:16.545422 progressemitter.go:225: DEBUG: progress emitter: deregistering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+т
екст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.545422 rwfolder.go:217: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 changed 1
[K2KRE] 2017/11/09 15:17:16.545422 rwfolder.go:311: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 c 2 p 64
[K2KRE] 2017/11/09 15:17:16.587622 rwfolder.go:1070: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 need file 1986 - 1988 - крахмальный-ЦТШ\Крок
и+текст\ptirerix3.jpg; copy 0, reused 4
[K2KRE] 2017/11/09 15:17:16.588622 progressemitter.go:211: DEBUG: progress emitter: registering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+тек
ст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.588622 rwfolder.go:1154: DEBUG: not weak hashing 1986 - 1988 - крахмальный-ЦТШ\Кроки+текст\ptirerix3.jpg. file did no
t contain any weak hashes
[K2KRE] 2017/11/09 15:17:16.593622 rwfolder.go:1435: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 closing 1986 - 1988 - крахмальный-ЦТШ\Кроки+
текст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.593622 rwfolder.go:1367: DEBUG: file modified but not rescanned; not finishing:
[K2KRE] 2017/11/09 15:17:16.593622 progressemitter.go:225: DEBUG: progress emitter: deregistering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+т
екст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.593622 rwfolder.go:217: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 changed 1
[K2KRE] 2017/11/09 15:17:16.593622 rwfolder.go:311: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 c 2 p 64
[K2KRE] 2017/11/09 15:17:16.632622 rwfolder.go:1070: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 need file 1986 - 1988 - крахмальный-ЦТШ\Крок
и+текст\ptirerix3.jpg; copy 0, reused 4
[K2KRE] 2017/11/09 15:17:16.632622 progressemitter.go:211: DEBUG: progress emitter: registering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+тек
ст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.632622 rwfolder.go:1154: DEBUG: not weak hashing 1986 - 1988 - крахмальный-ЦТШ\Кроки+текст\ptirerix3.jpg. file did no
t contain any weak hashes
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:1435: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 closing 1986 - 1988 - крахмальный-ЦТШ\Кроки+
текст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:1367: DEBUG: file modified but not rescanned; not finishing:
[K2KRE] 2017/11/09 15:17:16.641622 progressemitter.go:225: DEBUG: progress emitter: deregistering SyncThing 1986 - 1988 - крахмальный-ЦТШ\Кроки+т
екст\ptirerix3.jpg
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:217: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 changed 1
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:257: INFO: Folder "SyncThing" (SyncThing) isn't making progress. Pausing puller for 1m0s.
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:258: DEBUG: sendReceiveFolder/SyncThing@0xc042186900 next pull in 1m0s
[K2KRE] 2017/11/09 15:17:16.680622 progressemitter.go:240: DEBUG: progress emitter: bytes completed for SyncThing: 0
[K2KRE] 2017/11/09 15:17:16.680622 model.go:627: DEBUG: model@0xc042184360 NeedSize("SyncThing"): {1 0 0 0 520415}

(Alexey T) #12

v 0.14.40 says File modified but not rescanned


(Jakob Borg) #13

This is the same issue as Folder isn’t making progress 2017 that we also don’t know the cause of. That’s on 0.14.39 though.


(Simon) #14

As far as I remember we didn’t change any logic in 39-40 regarding modification of files between scanning and pulling. We somehow need to find out why the subsequent scan does not pick up the file that is reported to exist here. I don’t really have any idea how to do that.

@Xeenych Just to be sure, can you please run with STRACE=model,scanner (preferably on 0.14.40) and either post the logs between two
[K2KRE] 2017/11/09 15:17:16.641622 rwfolder.go:257: INFO: Folder "SyncThing" (SyncThing) isn't making progress. Pausing puller for 1m0s.
lines or just upload the entire log as a file.


(Alexey T) #15

Yes, it looks like this. THe problem arised sometimes on older versions of ST earlier.


(Jakob Borg) #16

I found the a bug… Hang tight. :slight_smile:

Hitting “rescan” on the folder or letting a regularly scheduled scan happen should work around it though.


(Alexey T) #17

No-no. Rescanning does not help


(Jakob Borg) #18

Then it’s something else as well. Ah well. I can reproduce this but rescanning works for me.


Nah, it’s not that. The bug I found causes a full rescan (instead of just rescanning the file we need) when this discrepancy happens, but that should also solve the problem.

Any NTFS deduplication or similar enabled on your side?


(Alexey T) #19

I don’t know about deduplication. Default Win7 Home premium 64 installation


(Jakob Borg) #20

Oh, wait. I see the issue now. For real this time.

The case mismatch is the cause after all. To fix: delete or rename that PtiRerix.jpg, on either side, and let that sync. Then rename it back.

Actual root cause for developers: When we’re about to commit PtiRerix.jpg we check to see that the state on disk is what we expect from the state in the database. The database lookup for PtiRerix.jpg yields nothing, because the database is case sensitive and there is nothing it in by that name. We verify that the file doesn’t exist on disk either - but it does, as ptirerix.jpg. We figure it must have been created just now and not scanned yet, so we schedule a rescan. But the rescan will see it as ptiterix.jpg and we’re back to square one.