Does Syncthing reuse blocks from ignored files?

Development
#1

I have a question regarding ignored files. As far as I know, they are still indexed and kept in the database, but are blocks from them also reused for new similar or identical files that get added to the folder?

I am interested in reusing blocks from .stversions without actually adding the folder to Syncthing separately. I can remove it from the hard-coded list, which then makes Syncthing treat the folder as any other. However, then I would also like to ignore it, so that it is not synced to any other device. Will doing so allow Syncthing to use blocks from the .stversions folder locally, or is it all in vain?

The reason for the whole plan is that I often move huge folders, however not inside the same Syncthing folder, but rather between different ones. Because of that, what usually happens is that Syncthing deletes the files in the second folder on a remote device before it manages to move or copy them from the first folder. I would like to work around this somehow.

#2

No. Not read, not indexed, not reused from. Ignored is ignored.

2 Likes
#3

Thank you for the answer, although it does make the whole task more difficult. I have had a look at the code, but I was unable to find any obvious parts that I could modify to change the default behaviour.

Without heavy code modifications, I guess that I will have to try using some kind of a script to mass add all .stversions folders to Syncthing on start as unshared folders, so that the files from them will be reused for other folders later on.

#4

Actually, you may just add any folder that you want to have parts reused from and just not share it with any other device. At least, this has worked for me in the past.

I think I even used to it to reuse parts from previously deleted files in the .stversions folder.

#5

Since you’re into hacking it, one option could be to hack the config struct to auto generate unshared stversion-folders for each folder, or do the corresponding thing where a folder gets added to the model.

Another option would be a cleaner contribution to actually index versions properly. Perhaps a new flag per item to indicate that the file shouldn’t be announced.

3 Likes
#6

The first method looks easily doable with some hacking around, but as you say, the second approach is probably the right one, especially since doing so would benefit everyone, and also would not clog the config and GUI with tons of folders.

I will first need to see what I am actually able to do with my limited skill set though. Thank you for the ideas regardless :slightly_smiling_face:.

1 Like