Preset Manager shows wrong path that does not exist

Stefan · 2011-10-22 21:33

Andrew wrote:

Stefan wrote:
Which reason could that be?
Ideally to stop programs (and users) from storing user data or junk in system/program folders. UAC will even prevent a "normal" admin user from writing to these folders, since they are not "true" admins.

MS have done this to stop malware spreading itself automatically into trusted places.
But there is no harm in giving e.g. MODIFY rights to the group USERS or an single user on an (single!) sub-folder in program files.

If you do this, even an installed app like ReNamer will work properly as expected.

To do this, after installing ReNamer to "C:\Program Files\Renamer",
go to "C:\Program Files\" and right click at the "Renamer" folder.
- Properties
- Security tab
- Modify button
- select USERS
- check MODFIY
- OK

Next you have to create an "Presets" sub-folder
under "C:\Program Files\Renamer"
to get "C:\Program Files\Renamer\Presets"
or, if already exists, just move the folder from virtual store
"C:\Users\<yourName>\AppData\Local\VirtualStore\Program Files\ReNamer\Presets\"
to "C:\Program Files\Renamer".

On next start ReNamer will use this Presets folder.

(Note: AppData is an hidden folder, you have to go to the explorer options to un-hide such folders.
Or just type 'appdata' behind "C:\Users\<yourName>\" in the explorer address bar)

- - -

Or just don't install to "C:\Program Files\Renamer"
but to
"C:\Tools\Renamer" as Denis mentioned,
or perhaps to
"C:\ProgramFiles\Renamer" by removing the space from the folder name
and all works without any problem even on W7 with UAC.

If you still prefer "C:\Program Files\Renamer" or just want use an already installed ReNamer without doing this work around now,
you can go an other way an start ReNamer as admin:

Denis wrote:

When launching applications, user can specify to run it with administrative privileges.
Just right-click on the application icon and select "Run as administrator".
(From http://www.den4b.com/wiki/Compatibility)

- - -

Of course you can also use the portable zip archive as Andrew says and un-pack it to an place with write access.
The only disadvantage would be you get no shortcuts in start menu and on desktop automatically, but you could do this at your own.

- - -

Generally note:
As Andrew mentioned you may want to put your portable apps (and all your other data) to an other partition then C:.
That way you can reinstall windows on C: without losing your data on e.g. E:

- - -

Side note:
please note that on W7 with UAC all other written files like the ReNamer.ini
and your translit and script files will be also stored in that virtual store as long as
you stay with the default installation and don't have used one of our work around from above.

.

Stefan · 2012-12-19 20:38

Since my english is not the best i have searched for an description in other words and found them here e.g.:

http://drupal.org/node/1161522

File discrepancies caused by Windows Vista\7 "VirtualStore"
Last updated May 18, 2011.
It many cases the Windows VirtualStore shouldn't cause problems with AppName;
Windows virtualizes the location of any files written to it and the application reads the files from that location.
However, problems caused by VirtualStore have been reported
Background
Windows Vista and Windows 7 User Access Control (UAC) introduced a feature called the VirtualStore
which is designed to add an extra layer of security protection for applications installed under the Program Files folder.
All changes made to files in, and any attempt add files to, the Program Files folder and sub-folders (directory and sub-directories)
requires a special Administrative permission. This is done so that stray and possibly malicious programs and files do not intermix
with or overwrite legitimate ones to insure that Program Files is always intact and not corrupted.
Applications often write configuration and other temporary files within their own installation folder or sub-folders during normal use.
Because UAC is designed to ensure that Program Files remains completely unchanged from when applications were initially installed,
it prevents these files from being written and other changes from happening in all folders under Program Files.
Instead, changes to configuration files and additional added or temporary files are written to the VirtualStore.
This is located in the: /User/AppData/Local/VirtualStore folder, and corresponding sub-folders.
Possible Fixes
There are several ways to fix this problem, if it occurs on your system:
1. Disable UAC completely. This may be a good choice but it can introduce security issues because Program Files and other locations
will no longer be protected from possible malicious files or other changes.
2. Disable only the VirtualStore feature not the entire UAC. A possibly better choice if you feel this feature is not important
to the way you use your computer. This can be done by going to Local Security Policy -> Local Policies -> Security Options
and Disabling User Account Control: Virtualize file and registry write failures to per-user locations
3. Install AppName outside of Program Files. This may work in most cases and is certainly worth trying.
UAC is primarily designed to protect Program Files, not other locations.
4. Inform Windows UAC that it can trust the AppName application. This is probably the best choice if you're having this problem.
Under UAC applications do not normally run under Administrative level access; they use User level access instead.
(This is the way Linux and similar operating systems work.) However, you can tell Windows to trust AppName at the User level
and allow it a higher level of access than normal. This allows the application at the User level to write any changed or added
files to its folder and bypasses the VirtualStore.
This is done by right-clicking on the AppName folder under Program Files. Then click Properties that appears on the context menu.
The Properties dialog will appear. Click the Security tab and then select Users from the Group or User names: List box.
The permissions for Users needs to changed, so click the Edit button. Select Users from the Group or User names: List box.
Check the Full Control checkbox in Permissions for users:. Click through all the OK buttons and the permissions for users
will be changed for the AppName application.

srahulbose · 2013-08-10 16:11

Thank you for this thread.

I ran into a problem where the following was not working as expected.
"ReNamer.exe" /rename "abcd" C:\xyz

When I manually execute ReNamer and use preset "abcd" and location "C:\xyz", it worked. I spent some time figuring why this issue.

Issue was that ReNamer was not able to open the preset since Windows blocked it. Hence, things dint work. It worked when I manually ran the program, because it looked for the preset in
C:\Users\<yourName>\AppData\Local\VirtualStore\Program Files\ReNamer\Presets\
and not
C:\Program Files\Renamer\Presets

Dropped in to say, thank you :-)

Stefan · 2013-08-10 17:09

Thanks for the feedback.

Happy ReNaming.

den4b Forum

#11 2011-10-22 21:33

Re: Preset Manager shows wrong path that does not exist

#12 2012-12-19 20:38

Re: Preset Manager shows wrong path that does not exist

#13 2013-08-10 16:11

Re: Preset Manager shows wrong path that does not exist

#14 2013-08-10 17:09

Re: Preset Manager shows wrong path that does not exist

Board footer