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 problem is without a doubt with ImDisk. 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.Ĭode: Select all 08:13:43 INFO Working directory: C:\Program Files (x86)\Universal Media ServerĠ8:13:43 INFO Temp directory: R:\TEMP\UMSĠ8:13:43 INFO Logging config file: C:\Program Files (x86)\Universal Media Server\logback.xmlĠ8:13:43 INFO Logfile: C:\ProgramData\UMS\debug.log But, that means that the ramdrive isn't used, which isn't what you desire. You can easily get UMS running by setting the temp paths back to default og logging out and in again. I've also traced the issue back to the response Java gives when UMS queries permissions for any folder or a lmDisk ramdrive.
I've replicated the problem by installing ImDisk Toolkit myself (Win 7) and the problem is the same. In Java 6 and below there simply was no way to determine file permissions than to try and see what happens. 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.
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.
#Dataram ramdisk driver won't load software
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. I also tried to further explain that UMS isn't querying the file system itself to read the permissions, but asks Java nio. 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'd say that it's the old code that's rogue, even if it happens to work on your setup. 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. As explained before, I know why the behaviour changed.