Serversync Version: 2.6.17

Minecraft Version: 1.12.2

Issue: Sometimes files fail to copy over when syncing

Sometimes when doing a sync some files get removed but the new version isnt populated in. Is there a way to ensure this doesnt happen? I have a large pack and missing any files is always hard to figure out

Hello, please use the latest version of ServerSync. The new version solves many problems.

According to curse that is the latest 1.12.2 version. Or does your mod not care about the minecraft version since it runs on its own?

According to curse that is the latest 1.12.2 version. Or does your mod not care about the minecraft version since it runs on its own?

I see that you are using version 2.6.17, but the latest version is already 3.6.0. ServerSync can run without Minecraft. 3.6.0 still supports 1.12.2 to 1.16.2

ok. I will update and see what happens.

@Ceifeire ServerSync in it's recommended use works for any version.

There is mod loading code that starts SS for you when the forge environment starts, but I would generally not recommend using that.

Are you referring to the client or the server? I was hoping there was a way to boot SS with minecraft. Is there a way to run the server SS without booting the server itself?

Starting SS separately is the recommended method, you can check the wiki. SS can be started separately and works normally without starting the Minecraft server.

Are you referring to the client or the server? I was hoping there was a way to boot SS with minecraft. Is there a way to run the server SS without booting the server itself?

@Ceifeire Can you attach the logs from a failed run? There may be a crash happening there.

You can start SS when the server starts if you like, there are some limitations, for example:

• SS is tied to forge, if one crashes the other also dies
  • You also can not restart SS without restarting the minecraft server
• You can not assign different memory limits to SS and forge, they both stomp on each other
• Forge can and does manipulate code at runtime, this could cause SS to behave in unexpected ways
• Forge and SS share logging, this makes it harder to debug issues and clutters up your server logs with SS messaging (vice-versa)
• Having SS as a 'mod' means we have to put special handling in place to turn it into a 'server only' mod and ignore it during the sync process

One really cool reason for running SS and the Minecraft server separately is that you can continue to serve files to clients even if the Minecraft server is down for whatever reason.

Pretty much all of the issues are server side, the client just runs SS or plugs it into some automatic startup process.

There is also a preview of the new manifest style of sync here:
https://github.com/superzanti/ServerSync/releases/tag/v3.7.0-alpha.1

Note that it is very much bleeding edge though, so it probably has issues of its own.

ok. I will look into that more. I have come across a minor problem with the updated 3.6.0 version. This might be due to not running the sync server the recommended way but when the sync finished and starts the deletion process it gets hung up there and just sits indefinitely.

Alright here are the logs. one for the server itself and one for the connection established by a player.

Server Log
https://pastebin.pl/view/2e0eb269

Player connection log
https://pastebin.pl/view/3cd710da

LOG:Starting scan for managed configs: Sep 21, 2020
LOG:Include patterns: {
 
}
DEBUG:Failed to hash file: config
DEBUG:[sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
...

Interesting, looks like we might be trying to hash a directory. There is probably an issue in the file walker server side, though it should not stop the client from working.

The server is not happy after the sync process, seems like it finished but the client did not resolve so it is still trying to send a message to the server.

Closing this for now as the server code has had major changes for verson 3.x.x.