using HQM for example, if you want to sync all the quests in configs it will claim a sync is not required even though the file sizes are different because it uses the same name "quests.hqm", Please add an option to delete existing configs on the client and download new copies or compare file sizes with the server for new copies.

And if possible please add the ability to use *.cfg *.ini etc to copy all configs of that extension.

Shall, look into * 'wildcarding'.

An interesting bug indeed, thank you for finding it. Will probably need to have more than a file size comparison as there could be two different quest configs with the same file size.

The best option here might even be to allow forced config overwrite and add a checkbox or some such to the ui for turning it on/off.

Also, apologies for the late reply.

List<Excuses> legit = Queue.usualList;

Any luck? I'm not sure how the hashing happens yet, but couldn't one just hash the filename + contents of the config files in order to determine if it had changed? That way, it wouldn't depend solely on the filename and/or file size. Theoretically the only downside would be a possible performance drop from having to hash the contents of all the config files. But then again, I've never tried making a sync algorithm so I'm sure there is something I'm missing.

Haven't really had much of a chance to work on this. I had actually thought that the files get their contents checked

https://github.com/superzanti/ServerSync/blob/master/src/main/java/com/superzanti/serversync/util/Md5.java

Though it is entirely possible that configs are not using it.

The check function does appear to be hashing the file and sending that to the client for comparison.

util/SyncFile:

public boolean compare(SyncFile serversMod) {
 	if (!serversMod.version.equals(SyncFile.UNKNOWN_VERSION)) {
 		return this.version.equals(serversMod.version);
 	} else if (md5FileContents != null && serversMod.md5FileContents != null) {
 		return this.md5FileContents.equals(serversMod.md5FileContents);
 	}
 	return false;
 }

Probably an issue where the versions are comparing as the same file so the hash check is never run. Will have to do some testing.

Right...I knew I should've poked around the code before mentioning anything, lol. Currently building the dev environment up so I can further test as well. I'm noticing that it will download all the mods/configs just fine on empty directories, but after any sort of update to the server it appears to start having issues (the first referencing a java error in regards to an empty zip file, but when i tried to replicate for this documentation it is simply locking up at "received security details from server"). Not sure that these warrant new issues at this point though, if I see them persisting I'll open them up.

Seems more like its locking up when there are no mod changes to sync.

Removed a config and attempted sync: locked at sec details.

Added/Removed a mod and attempted sync: worked fine.

A second sync attempt directly after locked at sec details.

Fixed the GUI lock in 7c9ed7c

@shaynemk Should you manage to get the empty zip issue to show up again raise an issue for it. Empty zips/jars should be handled.

Did some testing with the current version of SS.
@CrowAU
Could not reproduce this issue, SS does sync these files when they are not identical. It might be that you had not added quests.hqm to the config include list?

Although current SS versions have config in the directory include list by default which needs to be fixed as this just syncs all config files regardless of the include list (generally not desirable from my experience)