mojira.dev

Kolja Nowak

Assigned

No issues.

Reported

MCL-1443 Windows Launcher mangles directory names if path to .minecraft contains symlink to network share, causing the game to freeze Invalid MCL-1444 Minecraft freezes in the menu when a click sound should be played Duplicate

Comments

Understood --workDir, thanks very much.

I tried it right now with a symlink to a share hosted by the same Windows machine which runs Minecraft, no real networking involved at all. Same result, i got ASSETS and SOUND. You should be able to replicate the issue easily by sharing a local folder and then replacing %AppData%/.minecraft with a symlink to that share.

In a cmd shell with Admin Privileges, do the following:

cd %AppData%
mklink /d .minecraft \\computer\sharename

I know that your Java code doesn't call CreateFile() directly, this is trivial, please 🙂

But your code calls some higher level Java functions, which, in the long end, lead to calls to CreateFile(). So still, whatever your code does will influence in some way how it gets translated to API calls by the JVM. The old Launcher didn't mangle any names, which is a strong indication that something changed on your side. Even if it is a bug in the JVM, you are triggering that bug now while you haven't in the old Launcher. (I traced the old Launcher too, it also uses OPEN_REPARSE_POINT, but translates the names always correct.)

From the perspective of a user, I'm not in a good position to report such a bug to Oracle. They will ask for demonstration, and you are owner of the code which demonstrates the problem. So from the perspective of a customer, I would expect that Mojang continues to investigate such a bug and take it to Oracle if needed. At least that is what professional software companies usually do. I already invested hours to nail down the issue to the point where your previous assumptions who is to blame where proven wrong... 😉

I don't understand the "--workDir symlinktarget" bit, couldn't find any documentation mentioning that flag. Can you explain further please?

Never mind, I created a new bug with a more precise summary and all information in one place: MCL-1443

I digged somewhat deeper and found clear evidence that this is a bug in the Launcher. Can you please reopen the bug, it seems I'm unable to.

The Launcher doesn't let the OS follow symlinks, but handles them by itself, and this handling sometimes introduces uppercase names.

I used ProcessMonitor (1) to watch javaw.exe when starting your Launcher with an empty .minecraft directory, and I compared what happens when .minecraft is a symlink and when not. With ProcessMonitor, you can see all Windows API calls done by a process, their parameters, and their results.

Windows has an API CreateFile() (2), which is used to open and/or create files and directories. This function would by default follow a symlink, returning a handle to the target of the link. That would make the link transparent to the application. But this function can also be called with the flag OPEN_REPARSE_POINT, which causes it not to follow a symlink, but to open a handle to the symlink itself, making it possible to modify symlinks, check where they point, etc.

Your Launcher calls CreateFile() with the OPEN_REPARSE_POINT flag, and if it hits a symlink, CreateFile() is called again with a translated path. Sometimes, this translations introduces uppercase names.

I will attach log files of my monitoring sessions, they can be viewed with ProcessMonitor. I've also made a screenshot, pointing to some log entries showing where a bad name translation happens.

(1) http://technet.microsoft.com/sysinternals/bb896645.aspx
(2) http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

This issue was already reported as MCL-1001.

Also, I made further tests, which show that a file system / OS / network server error is very unlikely, and that something must be wrong with the launcher. I described them in a new comment in MCL-1001.

I have exactly the same setup, with .minecraft being a symlink pointing to a network share, and I encountered the same problem. I already reported it as MC-28302, wasn't aware that I should have reported it as a launcher bug.

I strongly doubt this is a problem of the file system or the network server. If that would be the case, the same unintended conversion to uppercase should happen when using other programs to write the same data onto the same symlink. But that just never happens.

To prove this, I removed the symlink and started the launcher again, which then created and populated a fresh %AppData%/.minecraft folder on my local disk. Then I moved that folder somewhere else, reinstalled the symlink, and then copied the contents of the fresh .minecraft folder from my local disk via the same symlink onto the network. I did this multiple times using Windows Explorer, xcopy /e and another File Manager. I always got a correct copy with all directory names in lower case.

Directory name uppercasing really only happens when your new launcher is used in combination with a symlink to a network share. It doesn't happen in any other application, which creates directories below the symlinked network share. It also doesn't happen with your launcher, if the symlink points to a different directory in the same local filesystem, or if %AppData% directly points to a network share or network drive. I tried these combinations too.

So it must be some dark magic in the file system access layer of your launcher, maybe not in your own code, but in the libraries you use.

I would guess there is some code which does special casing for network drives and local drives, and then gets fooled by the symlink, because this effectively creates a drive which looks like a local drive but contains some directories which are on the network.

This also never happened with the old launcher, so maybe it would be interesting to think where your underlying methods to download stuff / write stuff to disk have changed in between.

Yes it looks so. However, I'm not convinced. I've never seen this problem before, and I use Windows symlinks pointing to network paths quite often for the Userdata of many of my programs and games. For example, my Firefox and Thunderbird profiles are redirected to the network in the same way. I just searched all those directories on the server side and couldn't find a single subdir whose name was completely uppercase. Maybe Java or some 3d party lib you use is to blame here?

Yes I know the Minecraft code references 'sound', because that is was the logfile tells us. The problem is the filesystem, which contains 'SOUND' instead, because the Launcher created it that way. Yes, I started with an empty .minecraft.

However, I retried it just now a couple of times, each time with a fresh .minecraft, and it looks the result is not deterministic. I sometimes got 'SOUND' and sometimes 'sound'. I also spotted more directory names which are sometimes uppercase and sometimes not, for example, in four tries, I got the following combinations for one specific subdir:

.minecraft/assets/SOUND/MOB
.minecraft/assets/sound/MOB
.minecraft/assets/sound/mob
.minecraft/ASSETS/SOUND/mob

I will attach full file listings of the state of .minecraft after a fresh install and launch of the game for all my four retries. I also attach the full debug log of the launcher from the last try. The log doesn't contain any uppercase names, so I'm somewhat puzzled from where they come.

My smb.conf doesn't contain the setting you mentioned, but it looks like it happens only when .minecraft points to the network share. I couldn't reproduce it on the local filesystem.