What happened?
.xiz's invisible in directory
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2017 from Närförort söder
To be is to do — Socrates.
To do is to be — Jean-Paul Sartre.
Do be do be do — Frank Sinatra.
To do is to be — Jean-Paul Sartre.
Do be do be do — Frank Sinatra.
-
- KVRian
- 1048 posts since 3 Jul, 2006
I can't reproduce the issue. When I save, I always see the file in explorer.
-
- KVRist
- Topic Starter
- 236 posts since 5 Oct, 2017 from Närförort söder
I finally found the answer. The files I've up til now considered "invisible" are stored in:
C:\Users\per99\AppData\Local\VirtualStore\Program Files (x86)\Common Files\VST2_x86\ZynAddSubFx\banks\Pers_egna
Of course I haven't created that path. The computer did it (without telling mig). And the same thing happens if I use the write function.
I have the latest W10 and I use ZynAddSubFx 521beta. May I ask if you used 521beta when you tried to replicate?
/Per
To be is to do — Socrates.
To do is to be — Jean-Paul Sartre.
Do be do be do — Frank Sinatra.
To do is to be — Jean-Paul Sartre.
Do be do be do — Frank Sinatra.
-
- KVRian
- 1048 posts since 3 Jul, 2006
I don't use Program Files (x86)\Common Files as root for my VST plugins, so here it doesn't do that.
I believe this is caused by Windows UAC (User Account Control), trying to protect everything under Program Files...
I was not aware that this was happening. I'm also not sure what I can do about it, because Zyn sees the folder actually being in Program Files (x86)\Common Files, and not in AppData\Local\VirtualStore.
This mapping procedure is completely obfuscated/hidden to the process (Zyn and its host) by the Windows Operating System itself, so Zyn has no way to detect or change this behavior.
Basically, Windows UAC does not allow programs that are not run with Administrator privileges to modify in anyway any file or folder structure under Program Files or Program Files (x86). If Zyn attempts to write a preset file, that is interpreted as a modification and is forbidden. In order that the program does not crash, it is told that the file is saved successfully, but under the hood it is relocated and the folder where it is stored is changed to be in C:\Users\...\AppData\Local\VirtualStore. This is all transparent for the program trying to save the file.
This is actually a compatibility "feature" for older programs (before Win Vista), that were allowed to store their own files within the Program Files folder.
I would expect that if you run your host application with Admin rights, and save a new preset, it would actually be saved in the Program Files (x86) folder as you expect. UAC is bypassed by programs running in Admin mode.
I suggest you keep your VST folder in a zone not protected by UAC, if you want complete control of your folders. Or you could turn UAC off... (but that may not be recommended due to security / malware concerns).
I use C:\VST or similar.
The desktop is already in C:\Users\...\... so that's why it was visible.
Normally, in modern days, files belonging to programs are stored under Program Files and are protected by Windows, while user data is stored under C:\Users\<username>.
But since the banks are coded to be read where the dll is, Windows decides to to this separation on its own.
BTW: In the Windows XP days (when I wrote this port), UAC did not exist.
I believe this is caused by Windows UAC (User Account Control), trying to protect everything under Program Files...
I was not aware that this was happening. I'm also not sure what I can do about it, because Zyn sees the folder actually being in Program Files (x86)\Common Files, and not in AppData\Local\VirtualStore.
This mapping procedure is completely obfuscated/hidden to the process (Zyn and its host) by the Windows Operating System itself, so Zyn has no way to detect or change this behavior.
Basically, Windows UAC does not allow programs that are not run with Administrator privileges to modify in anyway any file or folder structure under Program Files or Program Files (x86). If Zyn attempts to write a preset file, that is interpreted as a modification and is forbidden. In order that the program does not crash, it is told that the file is saved successfully, but under the hood it is relocated and the folder where it is stored is changed to be in C:\Users\...\AppData\Local\VirtualStore. This is all transparent for the program trying to save the file.
This is actually a compatibility "feature" for older programs (before Win Vista), that were allowed to store their own files within the Program Files folder.
I would expect that if you run your host application with Admin rights, and save a new preset, it would actually be saved in the Program Files (x86) folder as you expect. UAC is bypassed by programs running in Admin mode.
I suggest you keep your VST folder in a zone not protected by UAC, if you want complete control of your folders. Or you could turn UAC off... (but that may not be recommended due to security / malware concerns).
I use C:\VST or similar.
The desktop is already in C:\Users\...\... so that's why it was visible.
Normally, in modern days, files belonging to programs are stored under Program Files and are protected by Windows, while user data is stored under C:\Users\<username>.
But since the banks are coded to be read where the dll is, Windows decides to to this separation on its own.
BTW: In the Windows XP days (when I wrote this port), UAC did not exist.
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info
My music is on https://soundcloud.com/vdxi | Info | More Info
