Minecraft no longer follows windows symbolic links to a world in the save/ directory. When clicking on the "play" icon on the world selection page of the launcher, a message appears at the top right of the window: Failed to access level.
What I expected to happen was...:
I should be able to play via the Minecraft launcher a world in %APPDATA%\.minecraft\saves that is a symbolic link to the actual world
What actually happened was...:
I get the error message "Failed to access level"
Steps to Reproduce:
1. In a directory dedicated for running the server jar, start the server and create a new world – call it bug
Note: I run my server on my D:\ drive
2. Stop the server
3. Start a command prompt window "as Administrator"
4. Change directory to %APPDATA%\.minecraft\saves
5. Enter the command: mklink /d bug "d:\...path-to-server-directory...\bug"
6. Start the launcher, run 20w14a and attempt to play world "bug"
Being able to play a world solo and, when wanting to play the same world after starting a server, it is extremely useful to use a symbolic link. I do not relish copying a world back and forth while keeping track of which save is the most current. Attempting that will lead to inevitable errors. This is new as of 20w14a since the prior snapshots and releases (back to 1.12 at least) had no problem following symbolic links.
Linked issues
is duplicated by 1
relates to 1
Comments 4
Can also confirm for 20w14a, and that linked worlds have worked fine for years up until this point.
Here's an excerpt of the warning from the game log:
Failed to read level <WORLD> data
java.nio.file.FileAlreadyExistsException: C:\Users\<USER>\AppData\Roaming\.minecraft_snapshot\saves\<WORLD>
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:81)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:504)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:727)Another use for symbolic links (or so I've heard, I haven't tried it myself): having multiple profiles share the same resource pack folder. Especially helpful if you have 1gb audio packs (for example if you replace all 12 records with full length albums).
This still seems broken at 2020 July under Linux rather than Windows, even on the 20w29a snapshot (tested on Fedora 32, Ext4). Maybe the symbolic link issue needs to be fixed for Linux systems independently to the Windows issue?
If this needs a new issue created for the Linux specific symbolic bug let me know.
P.S. I think the main reason people use symbolic links is to backup their worlds or sync across computers using Dropbox (or equiv), maybe adding a setting into the Launcher settings to set where saves and backups are located could remove this issue moving forwards.
I can confirm this issue on Windows 10. Worlds using symbolic links used to work on older snapshots, but 20w14a now throws an error when trying to load the world.
I also have a server running on Ubuntu 19.10 that stores worlds in a different directory and points to them using symbolic links. This has worked in previous versions, but now throws an exception when trying to start the server.