Windows 7 VirtualStore folder

[admin]

I have XP Prof but no such tabs. Just this (looks the same whether from admin or from user account):

About the tab, I think it may not be a FAT32/NTFS issue, to see the security tab, you may try to disable simple file sharing in folder options (default is: enabled in Windows XP Professional so no security tab by default if I'm not mistaken).

Yes, sure I have NTFS, and simple file sharing in folder options is enabled (which is "recommended" by the way). So the problems with writing to the Programs folder as "User" only exist when you change the OS factory default to a setting that's not recommended? I can live with that.

[PeterH]

I have XP Prof but no such tabs. Just this (looks the same whether from admin or from user account):

About the tab, I think it may not be a FAT32/NTFS issue, to see the security tab, you may try to disable simple file sharing in folder options (default is: enabled in Windows XP Professional so no security tab by default if I'm not mistaken).

Yes, sure I have NTFS, and simple file sharing in folder options is enabled (which is "recommended" by the way). So the problems with writing to the Programs folder as "User" only exist when you change the OS factory default to a setting that's not recommended? I can live with that.

Sorry: I don't know exactly what I should answer.

MS - that are those people delivering a file system with security, and defining new users as administrators, just ignoring all of the possibilities. And then they recommend to use "simple file sharing" to switch-off security for NTFS? Very fine!
You know, why they do? They say, many unprofessional persons don't know about security, and complain, that they cannot write with a normal user to \Programme and such things. *These* problems are gone, if they ignore security. And if people by mistake delete the \Programme folder or so, MS says, *that's* their own fault.
That's like a manufacturer of cars recommending not to use seat belts - and when persons are killed they say, these should have driven slower.
But after a lot of critique MS has learned a bit - and has built UAC into their newer systems. That's like the car without seat belts, that stops when you reach 50km/h and asks you, if you really want to drive faster.
And the result: everybody complains about UAC - I'm afraid, you will with Win7, too. (And, if my expectation is right, you will not be able to use something like "simple file sharing" then?)

So let me say it that way: everbody should decide, what level of security he wants to work with. Now I'm convinced that it's more professional to work with available security, and so I want to do that. And I expect from a professional file manager to support me with this - and not to introduce any problems.

[ale]

I have XP Prof but no such tabs. Just this (looks the same whether from admin or from user account):

About the tab, I think it may not be a FAT32/NTFS issue, to see the security tab, you may try to disable simple file sharing in folder options (default is: enabled in Windows XP Professional so no security tab by default if I'm not mistaken).

Yes, sure I have NTFS, and simple file sharing in folder options is enabled (which is "recommended" by the way). So the problems with writing to the Programs folder as "User" only exist when you change the OS factory default to a setting that's not recommended? I can live with that.

Hello Don, I was merely pointing out why some people see and some don't see the security tab. I didn't really read the whole discussion and about the "problem", but about Windows XP, I think the "problem" of course lays not in the fact of showing or hiding a tab but in the actual set of permissions you were talking with Peter.

[admin]

If every XYplorer instance running from a protected folder auto-writes its settings to %appdata%\XYplorer: chaos! So an automatic solution is ruled out. But to prompt a non-savvy user (who is not able to handle the issue himself by startup.ini or command line) where to save the app data does not sound ideal either. So it could only be something semi-automatic like this:

when saving data:

Code: Select all

if no explicit app data folder has been specified
  if data cannot be written to the app folder
    tell the user that he lacks the rights
    ask him whether to write the data to %appdata%\XYplorer instead

on next startup:

Code: Select all

if no explicit app data folder has been specified
  if no data are found in app folder
    look for data in %appdata%\XYplorer

Good?

[PeterH]

Different kind of thinking here. Maybe I miss something...

For me: all logic at startup:
1) test for existent (and writable?) appdata folder (i.e. xyplorer.ini?)
2) if not found: search a location, create it, and continue like "found".

But the details: imagine you find appdata by startup.ini - but it's not writable. (Possibly the first run with a non-authorized user or such ) What to do? Use it and never write, or continue looking for appdata in other place? Or ask user? (Ask *what*?)

At creation a test for "writable" may lead to problem - as if this run may be from administrator (test ok), while next can be in user-mode: write forbidden.
This can *not* happen, if folder is user-specific: all users should have rights for their user-specific folder.

Sorry: not knowing much about XY and Windows (version-dependent) internals I think I should stop here.

[admin]

Which part of my suggestion didn't you like?

[PeterH]

Which part of my suggestion didn't you like?

I didn't go into depth - i just refered to your when: your general differentiation "when saving data" and "on next startup".
From my point of view all decisions about xydata should be made "at (every) startup", and later on any save (manual or "on exit") just this decision should be used.

The rest was about how to decide, which directory to chose for xydata. I seem to have no good idea in the moment.

[admin]

Which part of my suggestion didn't you like?

I didn't go into depth - i just refered to your when: your general differentiation "when saving data" and "on next startup".
From my point of view all decisions about xydata should be made "at (every) startup", and later on any save (manual or "on exit") just this decision should be used.

The rest was about how to decide, which directory to chose for xydata. I seem to have no good idea in the moment.

Why should a do a check at each startup which might not be needed (e.g. because user does not save any data)?

[PeterH]

Which part of my suggestion didn't you like?

I didn't go into depth - i just refered to your when: your general differentiation "when saving data" and "on next startup".
From my point of view all decisions about xydata should be made "at (every) startup", and later on any save (manual or "on exit") just this decision should be used.

The rest was about how to decide, which directory to chose for xydata. I seem to have no good idea in the moment.

Why should a do a check at each startup which might not be needed (e.g. because user does not save any data)?

Because at startup you could find a .ini, use it, and then for save use the directory of the found .ini?
I`d await that the first part always happens?

[admin]

Which part of my suggestion didn't you like?

I didn't go into depth - i just refered to your when: your general differentiation "when saving data" and "on next startup".
From my point of view all decisions about xydata should be made "at (every) startup", and later on any save (manual or "on exit") just this decision should be used.

The rest was about how to decide, which directory to chose for xydata. I seem to have no good idea in the moment.

Why should a do a check at each startup which might not be needed (e.g. because user does not save any data)?

Because at startup you could find a .ini, use it, and then for save use the directory of the found .ini?
I`d await that the first part always happens?

I think it's better to do the test write before the action. There can be weeks between startup and save configuration...

[PeterH]

I think it's better to do the test write before the action. There can be weeks between startup and save configuration...

Imagine: someone downloads XY, installs, and starts. Works and tries this and that. Then he's to do something else, must shutdown, and...
...XY comes with the last part of initialization: defining the location for xydata. Now he just should learn, where to put it, and why not elsewhere? I think he (just wanting to leave) will shutdown without save, and be angry.
This sitation normally will happen for a new installed xy - the next time the created .ini from the first run should be used. That's why I name it "initialization".

It's definitely something else than creating a document with word: I will save my document where I want. While the .ini is a "part of XY" - and I think that should be prepared together with installation and initialization, and not "weeks later".

Just my point of view...

[admin]

I think it's better to do the test write before the action. There can be weeks between startup and save configuration...

Imagine: someone downloads XY, installs, and starts. Works and tries this and that. Then he's to do something else, must shutdown, and...
...XY comes with the last part of initialization: defining the location for xydata. Now he just should learn, where to put it, and why not elsewhere? I think he (just wanting to leave) will shutdown without save, and be angry.
This sitation normally will happen for a new installed xy - the next time the created .ini from the first run should be used. That's why I name it "initialization".

It's definitely something else than creating a document with word: I will save my document where I want. While the .ini is a "part of XY" - and I think that should be prepared together with installation and initialization, and not "weeks later".

Just my point of view...

I could easily do it without the prompt (if that's the problem):
when saving data:

Code: Select all

if no explicit app data folder has been specified
  if data cannot be written to the app folder
    write the data to %appdata%\XYplorer instead

on next startup:

Code: Select all

if no explicit app data folder has been specified
  if no data are found in app folder
    look for data in %appdata%\XYplorer

Easy, but not portable (otherwise I would have done it long ago).

[Pagat]

sorry if this was already covered but: why don't you handle this during the installation (in the installer)? There you can ask whether or not to install XY portable. If not, you put a "startup.ini" into the program directory and ask for the data path (current user, all users, ...). During the installation you usually have admin rights and therefore no problem to write startup.ini.

The non-install version is for "experienced users" anyway who know what to do...

or do you actually want a solution for the non-install version?

[admin]

sorry if this was already covered but: why don't you handle this during the installation (in the installer)? There you can ask whether or not to install XY portable. If not, you put a "startup.ini" into the program directory and ask for the data path (current user, all users, ...). During the installation you usually have admin rights and therefore no problem to write startup.ini.

The non-install version is for "experienced users" anyway who know what to do...

or do you actually want a solution for the non-install version?

I don't think such questions should be asked during installation. At least it would clearly reduce the appeal of the app to first time users. Too unsmooth.

[PeterH]

sorry if this was already covered but: why don't you handle this during the installation (in the installer)? There you can ask whether or not to install XY portable. If not, you put a "startup.ini" into the program directory and ask for the data path (current user, all users, ...). During the installation you usually have admin rights and therefore no problem to write startup.ini.

The non-install version is for "experienced users" anyway who know what to do...

or do you actually want a solution for the non-install version?

I don't think such questions should be asked during installation. At least it would clearly reduce the appeal of the app to first time users. Too unsmooth.

I don't know anything about installers - so this maybe is not possible...
...but I like the installer, too. Just some ideas:

The installer asks for the install-directory - why not for portable? (With default = non-portable.)
Even better: if installer can decide whether install-directory is on removable media or so? Then dflt=portable?

And: the installer asks for "only current or for all users". If folder goes to Application Data, and "All Users" requested, use \All Users\Application Data\ else \<current user>\Application Data