Universal Media Server | Forum

As explained before, I know why the behaviour changed. There's nothing "rogue" about it, the change reads file permissions instead of trying to write a file and then deleting it again to check for write permission. I'd say that it's the old code that's rogue, even if it happens to work on your setup. I consider that an improvement, and the check itself isn't just used for checking the temporary folder but everywere were UMS requires write permissions.

I also tried to further explain that UMS isn't querying the file system itself to read the permissions, but asks Java nio. The problem is that Java nio's reply is wrong, and then one can wonder where the actual flaw is, if it's a flaw in Java (nio), in Windows or in the software emulating a drive. Whereever it is it's beyond our control. That doesn't mean that any Java application running on that system will fail, but it makes it probable that any Java application that queries write permissions on that type of virtual drive will fail.

Java nio (short for "new i/o") is new with Java 7, so it's not a big surprise that not a lot of application uses it yet. In Java 6 and below there simply was no way to determine file permissions than to try and see what happens.

I've replicated the problem by installing ImDisk Toolkit myself (Win 7) and the problem is the same. I've also traced the issue back to the response Java gives when UMS queries permissions for any folder or a lmDisk ramdrive.

The question is what to do about it. You can easily get UMS running by setting the temp paths back to default og logging out and in again. But, that means that the ramdrive isn't used, which isn't what you desire. I'd like to find a solution without going back to testwriting to any folder we check for write permissions, but it's doubtful that there's anything we can do about it.

I've found the root cause of the problem, when trying to read the write permissions Windows throws an error saying:

This is most likely caused by this Java bug. The bug is fixed (actually a workaround is found, the core bug is in Windows itself), but only in Java 9 - which is scheduled for release in 2017.

The root of the problem is probably some hackery on lmDisk's part in mounting the drive. The bug talks about "subst", an old MS-DOS command that's still around, but that was written in a time where file permissions wasn't a concept (FAT, FAT32). But, it's clear to me that the bug can be caused by other similar techniques. The root of the problem is that the drive doesn't properly return it's root path when asked to, and that somehow confuse Windows' API for accessing file permissions.

I installed the free version of (Max 4GB in the free version) and configured it to run on R:\ rerouting the TEMP and TMP folders to R:\TEMP. UMS fires up and uses the RAMDisk without a hitch:
The problem is without a doubt with ImDisk. I think it's a stretch if we should code UMS to fit bugs in other software, even though we have to do that with the transcoders. The workaround for subst made in Java 9 might still solve it, because the result of the bug is identical to the one we get with ImDisk. Still, it's a long wait for that to arrive.

I'm unsure what we can and should do about it, but you should contact ImDisk's author and let him know about it. I doubt this extremly unfortunate combination of Java's lacking handling of Windows' shortcoming with a path that cannot correcly report it's root path is very common in combination with ImDisk, so I doubt it's known to him. This is the document I found that best describe in detail what is failing with subst, and I'm betting that chances are good that ImDisk's author will figure out what the problem is merely by reading that.

In calling it "rogue", I was only referencing the fact that it broke on my config - I know your team designed the new coding intentionally, and it was more a tongue-in-cheek phrase than an offense to your programmers.

As for the rest of it, not much makes sense to me - but I will certainly direct the IMD programmer to this thread, as obviously it will make more sense to them, and they have the ability to do something about it. I'll just stay on 5.2.3, I guess, until 2017

Thanks for all your help, it really has been above & beyond expectations - hopefully you'll play with your new RAMdrive, and come to love it as I have!

I've made a workaround for the bug since it looks like it's going to be with us for a while. I think I've found a way to identify this condition, and when I do I fall back to the old way of test writing to the disk to determine if it's writeable. In the case of a RAMDisk it doesn't do any damage, and even if someone has used "subst" I guess it's better that it works than fails even if it means needless writing to the disk.

I've uploaded a Snapshot with this workaround, and I'd appreciate if you'd test it and report back.

When it comes to the installed RAM drive(s) they are leaving my system. I need all the RAM i have for it's intended purposes (16 GB and have had out of memory issues lately when having a lot of stuff open), and I generally spend very little time waiting for my system as it is. I guess it all comes down to your setup. RAM is comparably much more expensive per GB than even fast disks or SSD's, so from that perspective it doesn't make much sense.

I do use a RAM drive on one of my computers, but that's running Linux and has an SSD as OS drive. I usually don't use SSD's as OS drives because of their unreliability when written frequently, but in this case it is a matter of physical space restrictions forcing me to use a mSATA SSD as OS disk. In that setup it makes a lot of sense since I want the SSD to last as long as possible, and I've also redirected logfiles there in addition to the temp folders.

Nadahar wrote:...but you should contact ImDisk's author and let him know about it. I doubt this extremly unfortunate combination of Java's lacking handling of Windows' shortcoming with a path that cannot correcly report it's root path is very common in combination with ImDisk, so I doubt it's known to him. This is the document I found that best describe in detail what is failing with subst, and I'm betting that chances are good that ImDisk's author will figure out what the problem is merely by reading that.

I have done this, and got a reply mere hours later - you guys have been utterly amazing:

Hi,

I haven't read through all of the discussions you link to, but I assume there is something in the Java libraries that directly or indirectly requires interaction with Volume Mount Manager, which drives like ImDisk do not support. ImDisk is designed to be as small and simple as possible. Unfortunately, the way it works means that certain features that various system components and other software expect may not be supported. For instance, ImDisk drives do not show up in Disk Management, they cannot be assigned drive letters or mount points using "mountvol" command, they cannot be used with features like Volume Shadow Copy Services, several backup, database or virtualization applications and similar. I have some information about the issues and alternative drivers on the website: http://ltr-data.se/opencode.html/#ImDisk (scroll down to the paragraph about compatibility).

So basically, if Java libraries needs a drive that has a "root directory" managed by Volume Mount Manager to be able to know what kind of drive it is working with, ImDisk is simply not the right choice here. We have other disk virtualization drivers that support full disk emulation via a virtual SCSI adapter. It adds a little more complexity to setup and interaction but I guess it should solve the problems in your case.
GitHub repository: https://github.com/ArsenalRecon/Arsenal-Image-Mounter
You can run the GUI application here first to get the driver installed: https://github.com/ArsenalRecon/Arsenal ... plications
Then, you can download aim_ll.zip here to get the command line tools: https://github.com/ArsenalRecon/Arsenal ... plications

aim_ll.exe has a command line syntax that is very similar to imdisk.exe. If you, for instance use this command line now:
imdisk.exe -a -o awe -s 8G -m R: -p "/fs:ntfs /q /y /v:RAMdisk"
You simply switch to this:
aim_ll.exe -a -o awe -s 8G -m R: -p "/fs:ntfs /q /y /v:RAMdisk"

Happy New Year!

Regards,

--
Olof Lagerkvist
LTR Data http://www.ltr-data.se

-------------------------------------

Will install v5.4.1 now, and provide feedback and my Log file from that... I will probably end up upgrading to the enhanced tool as outlined above, since clearly this is what is being recommended (and if Java is going to start causing grief on other apps as well), but having the fix coded in certainly doesn't seem to hurt, and I will also install 5.4.0 when I do the above RAMdisk change and see if the "old new" code works on that.

This isn't the full, but I assume it gets far enough to determine if everything is working right - it seems so on my side!

DEBUG 2016-01-01 15:33:20.607 [main] Base path set to file:///C:/ProgramData/UMS/UMS.conf
DEBUG 2016-01-01 15:33:20.630 [main] FileName set to UMS.conf
DEBUG 2016-01-01 15:33:20.630 [main] Base path set to C:\ProgramData\UMS
INFO 2016-01-01 15:33:20.638 [main] Language not specified, defaulting to OS language.
DEBUG 2016-01-01 15:33:20.651 [main] Default logfile folder set to: C:\ProgramData\UMS
DEBUG 2016-01-01 15:33:20.769 [main] LogBack started with configuration file: I:\UMS\logback.xml
DEBUG 2016-01-01 15:33:20.778 [main] Fri Jan 01 15:33:20 MST 2016
DEBUG 2016-01-01 15:33:20.797 [main] PID file not found, cannot check for running process
DEBUG 2016-01-01 15:33:20.801 [main] Writing PID: 4016
DEBUG 2016-01-01 15:33:24.107 [main]
INFO 2016-01-01 15:33:24.107 [main] Starting Universal Media Server 5.4.1-SNAPSHOT
INFO 2016-01-01 15:33:24.107 [main] Based on PS3 Media Server by shagrath, copyright 2008-2014
INFO 2016-01-01 15:33:24.107 [main] http://www.universalmediaserver.com
INFO 2016-01-01 15:33:24.108 [main]
INFO 2016-01-01 15:33:24.108 [main] Build: 66dd4fbb2 (2016-01-01)
INFO 2016-01-01 15:33:24.108 [main] Java: Java HotSpot(TM) 64-Bit Server VM 1.8.0_66 64-bit by Oracle Corporation
INFO 2016-01-01 15:33:24.108 [main] OS: Windows 10 64-bit 10.0
INFO 2016-01-01 15:33:24.108 [main] Encoding: UTF-8
INFO 2016-01-01 15:33:24.108 [main] Memory: 1138 MB
INFO 2016-01-01 15:33:24.113 [main] Language: English (United States)
INFO 2016-01-01 15:33:24.113 [main]
INFO 2016-01-01 15:33:24.114 [main] Working directory: I:\UMS
INFO 2016-01-01 15:33:24.119 [main] Temporary directory: R:\Temp\UMS
INFO 2016-01-01 15:33:24.120 [main] Logging configuration file: I:\UMS\logback.xml
INFO 2016-01-01 15:33:24.121 [main] Logfile: C:\ProgramData\UMS\debug.log
INFO 2016-01-01 15:33:24.121 [main]
INFO 2016-01-01 15:33:24.121 [main] Profile directory: C:\ProgramData\UMS
INFO 2016-01-01 15:33:24.122 [main] Profile directory permissions: drwx
INFO 2016-01-01 15:33:24.122 [main] Profile configuration file: C:\ProgramData\UMS\UMS.conf
INFO 2016-01-01 15:33:24.126 [main] Profile configuration file permissions: -rwx
INFO 2016-01-01 15:33:24.126 [main] Profile name: Viridel

Yes, it passes the point where it used to stop, so it seems like a success. I assume UMS is starting and working?

Nadahar wrote:Yes, it passes the point where it used to stop, so it seems like a success. I assume UMS is starting and working?

I can access my own files via the web interface, and I just got Galana to install and test with her PS3, and all seems to be beautiful. I have her debug.log, but I assume it's largely irrelevant since it's the same as mine (except for the found PS3 stuff), and she's working.

Yes, I don't need the log when it's working. Sounds like this workaround is a hit then.

Thanks again for some staggeringly impressive technical support, and hopefully what has been discovered can make your product even better in the future!