Serversync Version:

serversync-2.6.15.jar

Minecraft Version:

1.10.2 forge 1.10.2-12.18.3.2281

Issue:

updates the file then deletes the file
then on the next run update the file without deleting it

Sucessfully updated: morefuelsmod-1.10.x-1.6.0.jar
Sucessfully updated: advancedRocketry.cfg
Sucessfully updated: endercore.cfg
Sucessfully updated: EnderIO.cfg
Sucessfully updated: Guide-API.cfg
<>morefuelsmod-1.10.x-1.6.0.jar deleted

<>advancedRocketry.cfg deleted

<>endercore.cfg deleted

<>EnderIO.cfg deleted

<>Guide-API.cfg deleted

It seems to happen with certain pcs and a large number of updates. Suddenly my users are experiencing issues. We have been using server-sync for months. At any rate I have not had issues personally. Also all the reports come from computers with 8GB rams or less. Also fun fact weaker hard-drives seem to be a factor as well.

Fascinating, I really should set up some auto testing for the project 😄 .

Thanks for the info, gives me some starting points to investigate.

You know I am always glad to help :)

I have tried to debug the problem by looking at the equals() function, specifically this line, which leads to the deletion every other time.

[edit] Actually, it seems to be an issue with the mcmod.info file. Some mod authors add colours to the name and/or the version, like so: "§83.7.4".This seems to cause it, since when i edited the control string part away, the mod doesn't get deleted. Maybe some string sanitation might help?

I have added in a specific check, for now, that looks for these color formatting characters at the beginning of versions or names.

If it finds one it removes the character and the following character, all I could find about these seems to suggest that there is only one character after the identifier.

I was highly tempted to just enforce a reasonable versioning scheme by stripping anything that's not [0-9.-A-Za-z].

Considering mod authors can use any old string in these fields though it's much safer to just specifically search for what we know is causing issues, also the above search would leave behind the number used to indicate which color is desired. In theory that would not be a problem as both versions in the comparison would have the extra digit, it's not very clean though and would no doubt cause issues down the line eventually.

Testing required: 2.6.17

• Modify a mcmod.info file to use a special character in the version and or name string
• Test both modified and unmodified sync
• Make sure that files are not unexpectedly deleted

@DustRaven
Hmm, nice find.

It's quite possible that during the parsing of the mcmod file that color confuses the system. In which case some sanitizing could help, or if it's some specific standard we could find / make a parser for it.

At the moment the files are just being parsed as JSON.

Nope, still happening. The mod in question is Mr. Crayfishs Furniture Mod, maybe there is something else off with the mod?

Hmm, I'll try to do some debugging over the weekend.

I think I'll take a different tack on this one.

SyncFiles are set up with a hash of the file they represent when created, there's no particular reason not to use said hash for mod comparison rather than trying to play with user registered version strings.

I switched the hash comparison to be the only method of file comparison and removed the mcmod.info check entirely.

This does appear to solve the issue on my local test environment.

I have updated the attached build on 2.6.17 with this commit.

Closing this as the hash check resolves the faulty mod comparison.
@P3rf3ctXZer0 I have raised #98 for investigating your concerns about lower end machine issues.

Yeah, it works. The mod is no longer being deleted! Thank you very much!

@rheimus can I have a copy of the newer serversync.

@P3rf3ctXZer0
There is a built jar attached to the latest release here: https://github.com/superzanti/ServerSync/releases

This is the latest and greatest including the more recent update to file hash comparisons.

I'll do some final testing then put a release out on curse as well.

@frakier Could I persuade you to test out the 2.6.16.aplha.2 version in the releases section of this repository.

I have not been able to reproduce this issue.

I should have the server to myself this weekend I'll try to give it a test and report back.

Testing 2.6.16.aplha.2

Updating and then deleting the jar file...
I closed the app and reran it each time...
(First run)
Set everything up [made sure the morefuelsmod] was present and gave it a try...
-Successfully updated: mods\morefuelsmod-1.10.x-1.6.0.jar
...
<>morefuelsmod-1.10.x-1.6.0.jar deleted
(Second run)
Ran the sync again [no problems but at this point the mod did not exist]
Successfully updated: mods\morefuelsmod-1.10.x-1.6.0.jar
(Third run)
Ran the sync again
Successfully updated: mods\morefuelsmod-1.10.x-1.6.0.jar
...
<>morefuelsmod-1.10.x-1.6.0.jar deleted
(Fourth run)
Ran the sync again [no problems but at this point the mod did not exist]
Successfully updated: mods\morefuelsmod-1.10.x-1.6.0.jar

morefuelsmod-1.10.x-1.6.0.jar is till a problem but whatever you did fixed the other files which were
all cfg files.

Hope this helps let me know if you need more tests. Will also be submitting some other things I noticed while testing as issues.

Tired a test...
the mcmod.info for morefuelsmod, the "version": "", was empty changed it to "version": "1.6.2",
and reran the sync , still updates and deletes the file every other time.

Got your code in eclipse, going to look it over next week, not a great programmer myself but maybe I will spot something. Until then instructed the players to check the log and run twice if needed.

Most likely culprits are probably:

• SyncFile.java:populateModInformation
• SyncFile.java:equals

Code still has a fair amount of cleanup needed in style & location of files etc, hopefully its small enough to not be too overwhelming though 😄.

Having a blank version field would cause interesting problems, don't believe the equals method is catering for that at the moment, nice find.

Narrowed down the culprit though, ill do some testing on my end as well. See if I can discover the underlying problem.