MC-34205Follow 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.
Environment
Linux x86_64
Java 7
Linked Issues
Created Issue:
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.
Environment
Linux x86_64
Java 7
- Unresolved
- Open
- Unconfirmed
- servers.dat symlink
- 1.6.4
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.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.
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)A comment with security level 'global-moderators' was removed.
is cloned by
When viewing or modifying the client's server list, servers.dat is not modified/updated, but replaced with a new file.
The biggest issue that this creates is that links are replaced with real files, as the new servers.dat is a different file with a new inode.
In MC-34205, a similar issue was marked wontfix, because Java 6 could not tell a symlink from a real file. However, as Java 8 is the minimum required version as of Minecraft 1.12, there is no need to support the old code that handles servers.dat.
If code is only changed for symlinks, however, this will still cause an issue for anything that depends on the inode, such as hardlinks.
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Try using a hard link instead.
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?
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.
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.
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'.
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.
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:
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.
That is agreeable. I'll ask around with fellow staff to see what comes up.
Reopening, this is a valid issue. The game is overwriting files rather than editing them, causing the symlinks to be destroyed.
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!
Unpossible to fix, java(6) has no concept of symlinks or not.
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.
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.