I have Minecraft installed on SMB network share which mounted on Windows workstation as local drive "F:". And my %APPDATA%\.minecraft folder is symlink to "F:\mincraft". Don't ask why, it just works so. I decided make clean install of MC 1.6.1 but MC can't load level with error
Client> Error in class 'CodecJOrbis'
Client> Unable to acquire inputstream in method 'initialize'.
Client> ERROR MESSAGE:
Client> minecraft:sound/random/click.oggAfter short researching I found that some of internal resources was named in uppercase. For example "..\minecraft\assets\SOUND\" or "..\minecraft\libraries\COM\". After renaming all folders to lowercase all works fine. Seems like folders are not creating correctly by default.
Linked issues
Attachments
Comments 6
It is not always works so. Sometimes folders creates all in lowercase. Try to make clear install several times. I put in attachment log of launcher, samba config and output of "dir /S /AD %APPDATA%\.minecraft" command. Share "store"
from smb.conf mounted as disk F:\ in Windows. Symlink created by "mklink /D %APPDATA%\.minecraft F:\minecraft" command
Java has no knowledge of your share. The folders it makes are 'just regular folders', we create them as lowercase, if the underlying filesystem creates them as uppercase and then fails to return them when requested by the lowercase name its the mistake of that attached share.
Nothing we can do here.
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.
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
Never mind, I created a new bug with a more precise summary and all information in one place: MCL-1443
Cannot reproduce.