MUTOOLS

mutools · Post by **mutools** » Fri Jun 25, 2010 7:12 pm

uke wrote:I am on Windows 7. Although i am logged in as administrator, i have to confirm a dialog when writing to files in the program folder. Probably you do so in your code and suppress the upcoming error.

The MU.LAB code does nothing special, it just reads/writes from/to files.

If MU.LAB gets a response that a file cannot be opened for writing, then it also tries to open it read-only.

So it's still a strange situation as even if the Mulab.txt would have been write-protected by Windows for some security administration reason, then Mulab should have been able to open it read-only. Weird.

Also this thought: If Mulab.txt could not be opened read-only then also all graphic files should suffer from this, and so you won't be able to see the Mulab GUI.

There is still something i really don't understand.

uke · Post by **uke** » Fri Jun 25, 2010 7:22 pm

If you copy a MU.LAB installation into a write-protected folder, you would be able to reproduce this behavior and maybe debug the source. Good luck

mutools · Post by **mutools** » Fri Jun 25, 2010 7:36 pm

If Mulab.txt could not be opened read-only then also all graphic files should suffer from this, and so you won't be able to see the Mulab GUI.
I just don't get it. If you're willing to dig this out with me, then let me know and i'll make a special MU.LAB version that will do specific logging in order to narrow this down.

uke · Post by **uke** » Fri Jun 25, 2010 7:41 pm

No problem. Send me your special MU.LAB and i will check it and send the log file back to you.

cytone · Post by **cytone** » Fri Jun 25, 2010 7:51 pm

Try copying your MU.LAB directory out of program files to somewhere else (eg. c:\temp\) and running it from there. It could possibly be an issue with Windows 7 virtual store.

uke · Post by **uke** » Fri Jun 25, 2010 8:03 pm

I just copied it to C:\temp\ and it worked fine. After that i put it again to C:\Program Files\ and i had to confirm the copy as administrator (i hadn't with c:\temp\)

pljones · Post by **pljones** » Fri Jun 25, 2010 8:11 pm

Windows 7 seems pretty buggy to my in regards User Access Control.

I had two versions of MULAB - 3.0.x and 3.1.x - in separate folders under Program Files (x86). For the MULAB 3.0.x folder, Windows prompted for write access. For the 3.1.x folder, it acted like any other user folder, allowing me normal user write access.

My wife has also had some weird experiences with Windows 7 where it appears to allow a file to be written to a folder but it actually hasn't been written there. Where it's gone is anyone's guess. To the one user, it appears to be in place. However, to anyone else accessing that folder, the file hasn't been updated. (Again, the local user was missing permission to write the file - but this was to a network share, so not quite the same.)

cytone · Post by **cytone** » Fri Jun 25, 2010 8:18 pm

In Windows 7 if a file is changed in "Program Files" it stores it in

C:\Users\[user name]\AppData\Local\VirtualStore\Program Files\MULAB\...

and windows uses a pointer to reference the file. So you end up with two versions, the original in "program files" and the edited one in VirtualStore.
It's Microsoft's attempt to finally bring in the best practice of separating the application files from user data and it uses this method for legacy apps that do not store the user data in the Users directory.

Maybe something went wrong somewhere

sorohanro · Post by **sorohanro** » Fri Jun 25, 2010 8:24 pm

cytone wrote: Maybe something went wrong somewhere

Yep, here's my bet:
Something went wrong = Windows design
Somewhere = Microsoft.

uke · Post by **uke** » Fri Jun 25, 2010 9:00 pm

@cytone: You are right! I checked this and found the modified settings file at that location. What a mess!

mutools · Post by **mutools** » Fri Jun 25, 2010 9:12 pm

Yes, what a Windows mess indeed, especially because you're not informed as a user, when saving a file somewhere in the Program Files area, that it will be saved somewhere else.

Thanks a lot cytone for the hint!!

Thanks uke for your emails and helping in finding the reason.

I'll see what i can do to bypass this Windows shit.
(no promisses yet, will have to think about this, as it's not only about Mulab.txt)

mutools · Post by **mutools** » Fri Jun 25, 2010 9:24 pm

This issue is affecting much more than Mulab.txt!

E.g. when the user adds personal samples and/or MuSynth or MUX patches to his/her Mulab/User/Library folder then these files are also not really written there but at another location, and so MU.LAB won't find them and the user won't see them

Also when a skin designer edits some files in Mulab/App/Graphics, the problem will be there.

This is really completely messing up the whole Mulab folder structure.

mutools · Post by **mutools** » Fri Jun 25, 2010 9:28 pm

cytone, do you know if there is a way to tell Windows NOT to do this?

mutools · Post by **mutools** » Fri Jun 25, 2010 9:35 pm

Further thinking: Also updating Mulab.exe to the latest patch will not work, if i understand this 'virtual store' thing right.

uke · Post by **uke** » Fri Jun 25, 2010 9:42 pm

If you copy files to that folder (located at progam files) using the windows explorer, you will be asked to confirm the copy process. If you are an admin and confirms with OK, the update should work.

MUTOOLS

KVR Audio

EditorNavigation setting change does not work