Presets Directory in VirtualStore

report · 2009-02-14 14:14

Under Vista (in my case: Ultimate 32b) and when being logged in as a Windows standard user, the error message "System cannot find path." occurs for the following commands:
Presets | Browse
Presets | Manage | Edit

The reason for this bug is that Renamer looks under
%ProgramFiles%\<RenamerDir>\Presets
while only adminstrator users may write there.

Vista stores files written to %ProgramFiles%\ while writing access by the current user is prohibited here:
%Users%\<UserName>\AppData\Local\VirtualStore\
Program Files\<RenamerDir>\Presets

***

There are different possible solutions:

1) Store ReNamer.ini and \Presets in

%Users%\<UserName>\AppData\Roaming\<RenamerDir>\

While

%Users%\<UserName>\AppData\Local

is for local, typically temporary data,

%Users%\<UserName>\AppData\Roaming

is, AFAIK, the default choice under Vista for progam preferences stored in a file. \Roaming means that the preference can be read even on a different PC, although I cannot verify this because I use only one PC.

2) Write to %ProgramFiles%\<RenamerDir> but load or read files from their actual location %Users%\<UserName>\AppData\Local\VirtualStore\Program Files\<RenamerDir>. I do not know though if this works. Also it is an inelegant solution.

3) Allow the user to specify a directory for ReNamer.ini and \Presets of his choice. E.g., then the user might choose something like D:\ini\Renamer\

I suggest in particular (3) because
a) it is what I want (it would me allow to save my program preferences quite like my ordinary user data without extra effort and make it easier to manage Vista's integrity level, etc.) and
b) it works under all versions of Windows (Vista or not) while the programmer does not even need to understand the default paths of various Windows versions or the VirtualStore mechanism.

Andrew · 2009-02-14 14:24

report wrote:

The reason for this bug is that Renamer looks under
%ProgramFiles%\<RenamerDir>\Presets
while only adminstrator users may write there.

Where have you installed ReNamer? Is it under %ProgramFiles%? If so, that may be the cause of the error.

AFAIK, ReNamer checks the <RenamerDir>\Presets directory, i.e. wherever the EXE resides currently. For example, in my case the ReNamer directory is C:\Utils\ReNamerBeta, so it checks C:\Utils\ReNamerBeta\Presets.

Can you check if you still get the error by copying the dir out of %ProgramFiles% and running ReNamer from the new location? If not, then Denis might need to code some checks for those restricted dirs under Vista (ugh! )

P.S. I'd just like to add that IMO, ReNamer is portable as-is and I love that it doesn't spread its junk all over my hard disk like other bloatware does all too often. So the INI being created in the program dir (wherever that is) is wonderful, and I wouldn't want it dumped in some weird out-of-the-way location like %AppData% etc. Being self-contained in one single dir is simply awesome and makes it a snap to easily copy everything (presets, settings, scripts etc.) to another location (like a USB drive for example).

Last edited by Andrew (2009-02-14 14:35)

Stefan · 2009-02-14 15:44

ReNamer is portable and keep all files together in ONE main folder, thanks Denis for that!
You can install ReNamer in any folder you like, f.ex. "D:\Tools\ReNamer" or "C:\...\My Documents\ReNamer"
Anyway, install ReNamer in an folder you have write access too.

If you or an other person installed ReNamer with Administrator-Rights to f.ex. %ProgramFiles%,
you/he have to enable write access (rw) for USERS to that install folder too.

How to configure NTFS permissions for files and folders on NTFS partitions
http://www.tech-faq.com/nt-file-system- … ions.shtml

# Navigate to Windows Explorer
# Right-click the particular file or folder that you want to control access to, and click Properties from the shortcut menu.
# When the Properties dialog box of the folder/file opens, click the Security tab
- Select USERS
- check '[ ] Modify'
- click OK
Your done.
(this means you have an personal standard windows installation with default settings, if you are on an corporate pc, please as your administrator,
..... or just unpack an fresh ReNamer.zip from http://www.den4b.com/projects/ReNamer/ReNamer.zip into an folder you have right access to)

Last edited by Stefan (2009-02-14 15:46)

report · 2009-02-14 16:26

Andrew, Renamer is under %ProgramFiles%. I know that I could install it at a different place. However, it would make little sense under Vista because %ProgramFiles% does have specially protected user access rights and in particular no write access as a standard user and using ordinary applications like Renamer only as standard user is the intended usage.

If I should install Renamer anywhere else, like X:\MyTools\Renamer, I would first set the same user access rights, etc. for X:\MyTools as those of %ProgramFiles%.

This is how Vista intends and am very happy with this security design because it protects me from applications possibly attacking or accidentally disturbing the system. (I might even further restrict the access rights of Renamer but it is not an internet application so I do not do that. Simply having it under %ProgramFiles% is good enough for my purpose.)

If den4b wants to have me test Renamer from a different location, I would then do it to help him getting to know the behaviour under Vista. But it would require me to take security precautions, so please understand that I do not make this test just to meet your (or my) curiosity.

Stefan, I agree that a simple INI file and all in one directory is a good thing. Or rather was before Vista / Windows 7. Now I prefer a slightly different approach (except that most applications do not offer it yet): Put all applications' ini files in one directory like D:\ini. This allows me to make backups of all INI files without the superfluous EXE and DLL staff.

The Vista standard approach to have all under %Users% is not as practical because a) there is more than one user (and I do not need to distinguish preferences for each user; others do do that though) and b) %Users% contains a lot of noise like \TEMP and Microsoft files.

If the Renamer user could specify a directory of his choice, then he may still specify %ProgramFiles%\<RenamerDir> if he wants, e.g., portability. He might choose the ..\AppData\.. path if he prefers the Vista standard approach or the ..\Documents and Settings\.. path (or whatever it was called) under XP. Or he might choose something like D:\ini if he prefers my approach.

Anyway, I have intended to make the Presets directory suggestion in an extra thread to come soon.

Andrew · 2009-02-14 17:09

Well, I understand your situation a bit better now. It seems you're paranoid about security, which is not such a bad thing to be!

Looking at your suggestions now, we have:

1) Destroys true portability and single dir nature. Also would require check for OS as Vista has %Users%, but XP doesn't. Unnecessary complexity.

2) Is it even possible? Suffers from all problems of 1) as well. As you yourself said, an ugly solution.

3) I'm personally not in favour of a change, but if one was to be implemented by Denis, I would opt for this one:

report wrote:

3) Allow the user to specify a directory for ReNamer.ini and \Presets of his choice. E.g., then the user might choose something like D:\ini\Renamer\

It too destroys true portability and single dir nature, but only if the user wishes it to be so.

This way, when the INI is first created, ReNamer would ask for the directory to save it in, with the EXE's directory coming up as the default.

However, I foresee a big problem here. Currently, ReNamer can blindly create its INI etc. in the dir where the EXE resides. Now if the INI were to be saved in some other location, how would the program know where it was? Then it might have to save the path to a registry key or something, which I absolutely do not think is the way to go. So if this issue can be solved, then the solution might be feasible, else...

P.S. It suddenly occurred to me that there might be a way for you to have your cake and eat it too! How about storing the INI file outside %ProgramFiles% and creating a hard NTFS link to it in the ReNamer dir? No idea if it will even work, but maybe if you're lucky, ReNamer will save to the link, which the OS in turn will invisibly direct to the actual file stored elsewhere. What do you think? This article and this one should be of help to learn about creating hard links under Windows.

Last edited by Andrew (2009-02-14 18:09)

report · 2009-02-14 17:21

I have never tried to hardcode Windows links except those for the desktop symbols because a) I would need to manage what I do by manually logging it and b) I would have to repeat all that stuff in cases like a Windows reinstallation (already now my workload per Windows reinstallation is 3 days plus preparation; although I need to do it only once every, say, 2 years, the thought of yet extending the typical duration beyond 3 days is, eh, unthinkable.

You suggestion is good (if it should work) as such but impractical. Recall that, to make sense, I would have to do it for every application. So instead of "only" managing preferences files, I would have twice the amount of work with also having to managing the hard links.

***

Off-topic: paranoid about security? Sure. Everything else is too risky in these years of exponential growth of numbers of malwares. Here is my small contribution to security:

http://home.snafu.de/jasiek/vista_security_concept.html

Last edited by report (2009-02-14 17:22)

Andrew · 2009-02-14 17:25

report wrote:

You suggestion is good (if it should work) as such but impractical. Recall that, to make sense, I would have to do it for every application.

Well, I meant for you to use it only in this case, but oh well!

So, any suggestions on how to solve that issue with suggestion #3?

report · 2009-02-14 17:32

Well, easy enough. There are actually several possibilities. E.g., one might also allow a click on the path shown in Presets Manger. First I had a new menu command Presets | Directory in mind, which is just a plain and simple dialog box. I still like the idea. But.. you are right that it also makes sense to ask for the path during the installation process already, except that I do not recall how Renamer installs; is it an installer or is it installed by simply copying the files? Only if it is an installer (or setup.exe), then it would make sense to ask for the preferences directory during the installation routine. (Some other application of mine did that.) Since not every user wants to change the path, show the editable default, i.e. the same as the user has just entered for the program path.

Last edited by report (2009-02-14 17:33)

Andrew · 2009-02-14 17:48

Well, the Presets Manager could have a browse button. But, the INI directory is a separate thing altogether. The problem is, presets are loaded manually by the user but the INI isn't. So while the user can specify the path while loading a preset, asking for the path to the INI every time the program loads/exits is just plain ridiculous!

So let's get things straight:

1) Presets in another directory - Not too much of a problem

2) INI in another directory - A big problem

What do you feel now about #2?

P.S. ReNamer comes as both an installer and a portable app in a ZIP archive. I don't know whether the installer writes to the registry etc., 'cos I've never tried it out. It might, or it might just be unzipping the files to %ProgramFiles%\ReNamer. In any case, one has to keep all users in mind. Changing the INI path involves the registry, which IMO effectively kills the portable version.

report · 2009-02-14 17:55

For me, both (1) and (2) would make the greatest sense because I would like to store ALL preferences at one place. Already the extra subdirectory \Presets is a bit confusing, IMO, although it does have its justification as a subfolder of the program folder if it is stored there at all (so that one can separate permanent from dynamic files.

Why must the registry be involved? Is it? (I have not checked that yet for Renamer.) Since I think that a program should not use the registry at all(!), I do not share your fear that relocating the INI could create problems; it just needs to be moved as soon as the user does choose a new path for the presets directory.

den4b Forum

#1 2009-02-14 14:14

Presets Directory in VirtualStore

#2 2009-02-14 14:24

Re: Presets Directory in VirtualStore

#3 2009-02-14 15:44

Re: Presets Directory in VirtualStore

#4 2009-02-14 16:26

Re: Presets Directory in VirtualStore

#5 2009-02-14 17:09

Re: Presets Directory in VirtualStore

#6 2009-02-14 17:21

Re: Presets Directory in VirtualStore

#7 2009-02-14 17:25

Re: Presets Directory in VirtualStore

#8 2009-02-14 17:32

Re: Presets Directory in VirtualStore

#9 2009-02-14 17:48

Re: Presets Directory in VirtualStore

#10 2009-02-14 17:55

Re: Presets Directory in VirtualStore

Board footer