Fixed incorrect mirror related paths

[coldcode69]

Many of the paths have duplicate server (world) names.

Example: WORLD_DIR="$WORLDS_LOCATION/$1" Then using: $WORLD_DIR/$1 Resulting in: mscs/worlds/MyServer/MyServer

This prevented the server being copied to the ramdisk, completely breaking the feature. The server would however continue to run from the normal location making it appear to work.

[sandain]

Thanks for the patch. However, I'm not sure this is correct. The nested world names are created by the minecraft server and contain different content. /mscs/worlds/MyServer contains all of the configuration files for the world including mscs configuration files, while /mscs/worlds/MyServer/MyServer contains the actual world files (e.g., terrain, inventory, etc). If you are seeing /mscs/worlds/MyServer/MyServer/MyServer, then there is a problem and your patch would be right.

I'll try to take a closer look at this soon. This is not a feature that I use on my server, so I wouldn't be surprised if there is an issue. I just don't want to accept this change without a better understanding of the issue.

[sandain]

I should note that we setup this code originally to only copy the folder that contains the world data /mscs/worlds/MyServer/MyServer to the ramdisk, leaving the folder the configuration folder /mscs/worlds/MyServer in place to simplify the code and reduce the amount of data that was being moved around.

[coldcode69]

When I ran the script originally, without edits, and mirroring enabled, it would try copying from/mscs/worlds/MyServer/MyServer which didn't exist. /mscs/worlds/MyServer contains the server.jar, all configs, logs dir, etc, and the world dir. The world dir is created by the server jar, and is just named "world", this is what contains the terrain data. I can't see any situation where the current script would require the user specified server name twice. I also find it confusing that the servers are called "worlds", "servers" is more appropriate IMO, as they contain not just the world data, but the actual server jar, and it's configuration.

If you only want the script to copy the world data then the path should be /mscs/worlds/MyServer/world. However using something like Spigot would mean you also need /mscs/worlds/MyServer/world_nether and /mscs/worlds/MyServer/world_the_end. I personally don't see an issue with copying the entire server folder, especially since the script already works like that with my edits, and it covers world dir variations between server software.

Regardless, I am currently running servers using my version, and mirroring/ramdisks are now working properly, they did not before.

[sandain]

Ok, I see what is going on. You need to follow the directions for importing a working world into mscs part of the README.md file. You may also wish to follow the renaming world directions.

In your case, your world is named world, not MyServer (you can see this by looking at the name of the world in the server.properties file). Your world setup should be in /mscs/worlds/world/, and the Minecraft generated world files should be in /mscs/worlds/world/world/.

The server jar file does not belong in the world's folder, it will be placed in a separate folder /mscs/server/ since all worlds can utilize the same jar file (however, it doesn't hurt to have the jar file in the world directory, it just won't be used).

[coldcode69]

My mistake, I may have ran the server manually with the jar initially, requiring the import instead. Didn't seem like this was an issue as everything worked as-is. I find it a bit strange how well mine works considering my folder structure is nothing like that example in the documentation.

I am a bit confused about the logic behind changing the world folder name though. Keeping the jar in a shared directory makes sense, but I don't see how the rest makes anything easier, it certainly doesn't make it easier to understand the structure. The documentation suggest the /mscs/worlds/world folder, still contains config files, logs etc, so I still don't think "worlds" is the best terminology.

[sandain]

The directory structure is how I designed the script in 2011. I realize it is a bit confusing, but I don't want to change things around at this point and break people's config. Each world (or server if you prefer) requires its own directory. In this directory the world server keeps its configuration files (server.properties, logs, etc.) and a directory of the world's name (from server.properties) to hold all of the terrain, inventory, etc files. Since the script supports multiple worlds, I made the executive decision to place these in a folder using the world's name in /opt/mscs/worlds. This had the unfortunate side affect of having the nested /opt/mscs/worlds/MyWorld/MyWorld layout, but at this point, it is what it is..

[sandain]

I should mention that the script can still run a world in /opt/mscs/worlds/MyServer/world/ because the script (for the most part, as you have noticed) only cares about the MyServer part of the directory structure. When you start the server.jar, it looks at the server.properties file, finds the name of the world server (in this case world) and loads the terrain/etc data. I feel that it makes more sense for mscs and the minecraft server.jar to call the world server the same thing, so you just need to modify the server.properties file to have the same name as well as rename the world directory to the appropriate name. I could have left the minecraft server thinking that all world servers were named world, but I didn't.

I hope this helps you to understand my thought process back then..

[sandain]

Maybe what I need to do is add a couple new features to the script to automate the import and rename directions in the README, because I agree that this is somewhat confusing..

[sandain]

Closing this PR as invalid. I have a couple patches I'm brewing up to add import and rename functionality to the script.