[MC-34205] Follow symlinks when saving servers.dat

I have different game directories for different versions of minecraft. To not having to add all servers again with each profile, I symlink a main servers.dat to the specific profile dirs. So far everything works fine. The game follows the symlink and reads the main servers.dat.

But when I add a new server and it tries to save the servers.dat, it doesn't respect the symlink and just overwrites it with a normal file. Instead of following the symlink and overwriting the shared servers.dat.

Linked issues

is cloned by 1

MC-121927 Client deletes and replaces servers.dat Resolved

Comments 13

CubeTheThird 2013-10-07T14:05:53Z

Try using a hard link instead.

Guybrush Threepwood 2013-10-07T21:09:07Z

Joker.

This ticket is neither invalid nor resolved.

This could be fixed by a simple fix in the code.

And please elaborate to me how i shall hardlink a file on a different filesystem?

CubeTheThird 2013-10-07T22:08:43Z

If this is across different filesystems then I have no alternative suggestion. This report is invalid as you are not reporting a bug in Minecraft's current functionality, but are rather requesting a change to it. For feature suggestions or changes please do this on Minecraft Suggestions on Reddit.

John 2013-10-08T00:55:27Z

Seems like a bug to me. Minecraft respects the symlink when reading servers.dat, but ignores the symlink when writing. That behavior is inconsistent.

By your 'current functionality' logic, you could argue than fixing any existing bug is a change to Minecraft's current functionality, and therefore is a feature request.

Minecraft's treatment of symlinks in this situation is inconsistent and unexpected behavior. I can't imagine why this inconsistency would be considered a feature of the current version.

Bug: Minecraft follows symlink when reading, but ignores symlink when writing.

Guybrush Threepwood 2013-10-08T01:07:50Z

Thanks John. I couldn't have stated it better 🙂

But apparently the mods here rather close bug tickets then get them fixed. I saw that a few times already. If this is what you understand under a bugtracker, then you can also just close it down completely and redirect everyone to r/minecraftsuggestions for the 'suggestions'.

3 more comments

CubeTheThird 2013-10-08T01:45:16Z

John you are correct in one respect, and both to you and Guybrush I apologize if it appears I am being unjust. I did not clearly explain what I mean by current functionality. What I mean by this is more along the lines of current expected functionality. The way this file is read and written works as the client expects: on the actual file. By saying you are making a request, I mean that you are asking for additional functionality to be added here.

Furthermore, I believe there may be some confusion as to the functionality of symbolic links. These are a filesystem construct which, when handled by the operating system, direct applications to the linked file. As far as the Minecraft client is concerned, it is accessing the file directly, as the linking process is transparent.

John 2013-10-08T03:56:10Z

CubeTheThird, to be fair, you and the other mods on this tracker have a pretty rough job. Most of the bugs are of pretty poor quality, so I don't you blame you for being heavy-handed. But this doesn't relate to the technical discussion.

I agree completely with what you wrote about symlinks. However when writing, this is precisely what the client is NOT doing:

As far as the Minecraft client is concerned, it is accessing the file directly, as the linking process is transparent.

Instead of following the symlink on writes, it is deleting the existing symlink, then writing (or overwriting the actual symlink with the new server.dat).

Before adding a server to the server list:
user@computer:~/.minecraft/1.6.4/.minecraft$ ls -l server*
lrwxrwxrwx 1 user user 25 Oct 7 20:35 servers.dat -> /home/user/.minecraft/servers.dat

After adding a server to the server list (I had to edit the second line so that the perms didn't show as 'deleted'):
user@computer:~/.minecraft/1.6.4/.minecraft$ ls -l server*
- rw-r-- r-- 1 user user 731 Oct 7 20:40 servers.dat

If deleting the old file and writing a new file is the intended behavior, then I guess this does belong in a feature request. However, I can't imagine why the original isn't just overwritten instead. I think it is more likely that this was coded without any consideration for filesystem features such as symbolic links. Hence, I think this is a bug.

Guybrush, if you do post this on /r/minecraftsuggestions, please post the link here. I'd like to see their reactions. My guess is that you will downvoted and told to post it to the bug tracker. 😞

CubeTheThird 2013-10-08T04:21:29Z

That is agreeable. I'll ask around with fellow staff to see what comes up.

Ezekiel 2013-10-08T14:13:31Z

Reopening, this is a valid issue. The game is overwriting files rather than editing them, causing the symlinks to be destroyed.

John 2014-05-12T19:03:52Z

Bug is still present with Minecraft 14w19a and Launcher 1.4.2. Please update affected versions (or tell me how to do it myself). Thanks!

Erik Broes 2014-07-30T12:00:46Z

Unpossible to fix, java(6) has no concept of symlinks or not.

Guybrush Threepwood 2014-07-30T16:55:14Z

Shouldn't this work on it's own anyway? Maybe the problem is how you save it. Are you moving/copying a temporary copy of the file on top of the file to write to it? Just guessing here, could also just be a weird java problem.

Torabi 2014-08-20T14:10:49Z

I believe it's common programming practice when editing files on disk to instead write the whole file out to a new file, then rename it over the old one, unless the file has a fixed-length record structure, or is being managed through a database or filesystem-like framework. This is significantly simpler to do, because it makes editing a file into the same process as writing it from scratch, and you conveniently avoid all the gotchas of tracking changes and random access writing. It also makes the process more resistant to data loss, because if the writing process fails at any point before the rename, you still have the old file as a backup. And the rename should be an atomic operation at the OS level that either fails completely with no damage, or succeeds completely.

Unfortunately, this will break symlinks, because a rename operation (like mv) will operate on the symlink itself, rather than its target. Preserving symlinks requires either doing things the hard, naive way (or getting a library to do it for you), or being able to detect symlinks and deliberately follow them to find the target. Java 6 doesn't have this capability, but Java 7 does, so fixing this would require bumping up the minimum required java version, using an external library of some sort, or writing OS-specific calls. Though supposedly there's a way to check for symlinks by comparing the canonical path to the absolute path.