Page 4 of 4

Posted: Mon Nov 21, 2011 10:00 am
by gfb107
My intention was to
  • If rmaster.err/RemoteMaster.properties can be written in the installation folder, use the installation folder.
  • Otherwise
    • If running under Windows 6 or later, use %APPDATA%\.RemoteMaster
    • Otherwise use "user.home"/.RemoteMaster
I guess the problem is that Windows doesn't prevent writing to the installation folder (in Program Files), but silently redirects to another, hidden folder?

Posted: Mon Nov 21, 2011 10:01 am
by xnappo
gfb107 wrote:My intention was to
  • If rmaster.err/RemoteMaster.proeprties can be written in the installation folder, use the installation folder.
  • Otherwise
    • If running under Windows 6 or later, use %APPDATA%\.RemoteMaster
    • Otherwise use "user.home"/.RemoteMaster
I guess the problem is that Windows doesn't prevent writing to the installation folder (in Program Files), but silently redirects to another, hidden folder?
Yep - exactly.

How about bringing up a save dialog with where to save the log file?

I think using the system-specified temp dir is the right thing to do(in general), but the temp directory is not the right place for the error log...

xnappo

Posted: Mon Nov 21, 2011 10:07 am
by gfb107
Well, maybe my changes would work if the installation folder was actually made read-only? That is what this thread is about, after all :)

Posted: Mon Nov 21, 2011 10:27 am
by eferz
mathdon wrote:Oh, that's really wonderful. Make Windows users run through hoops to get sensible behaviour, just so Linux users get a nice default behaviour.
The java.io.temp variable has nothing to do with Linux or Windows specifically. It is a java platform behavior dependent on how each operating system implements Java. Also, the users would not have to "run through hoops" as you put it since the install scripts which gfb107 creates does most of the work for RM and RMIR shortcuts.
gfb107 wrote:My intention was to
  • If rmaster.err/RemoteMaster.properties can be written in the installation folder, use the installation folder.
  • Otherwise
    • If running under Windows 6 or later, use %APPDATA%\.RemoteMaster
    • Otherwise use "user.home"/.RemoteMaster
I would recommend using the %LOCALAPPDATA% instead of %APPDATA% which doesn't need to get copied to servers.

I'm not sure, "user.home" was meant for windows or linux, but I believe "%HOMEDRIVE%%HOMEPATH%" are the appropriate windows variables and "~" is the home equivalent for Linux.
xnappo wrote:I think using the system-specified temp dir is the right thing to do(in general), but the temp directory is not the right place for the error log...
I agree too.

Posted: Mon Nov 21, 2011 10:43 am
by eferz
gfb107 wrote:I guess the problem is that Windows doesn't prevent writing to the installation folder (in Program Files), but silently redirects to another, hidden folder?
I believe that is dependent on whether or not User Account Control (UAC) is enabled, because whenever a user has to authorize actions as a Administrator for anything written to the Program Files, Program Files (x86), ProgramData, or Windows directories, it will then write to %LOCALAPPDATA%\VirtualStore to maintain system integrity for all users.

Posted: Mon Nov 21, 2011 11:21 am
by mathdon
Personally, I don't want the properties file in my install folder. I have several copies of RM in different folders, of different versions, and I want them all to access the same properties file. I was very happy with the way things were before these changes were made.

Posted: Mon Nov 21, 2011 1:46 pm
by vickyg2003
:?:
I don't have a Win7 computer here right now so I can't do experiments, but I am familiar enough with the virtualstore concept that I realize what horrible problems they can cause.

I don't see me ever installing any of the JP1 tools in the Program Files area simply because of the restrictions Windows puts on the folder. I tweak protocols ini and RDFs. I don't see how you could possibly do that with Win7.

If the RDF's are stored in the Program Files subdirectory, wouldn't they be subject to all that virtual stores problems. If SVN is run from within RMIR, would IR be able to see the changes? Or since RMIR did the change at a time not during installation, would these go into virtualstores for RMIR use only?

Posted: Mon Nov 21, 2011 2:35 pm
by eferz
vickyg2003 wrote::?:
I don't have a Win7 computer here right now so I can't do experiments, but I am familiar enough with the virtualstore concept that I realize what horrible problems they can cause.

I don't see me ever installing any of the JP1 tools in the Program Files area simply because of the restrictions Windows puts on the folder. I tweak protocols ini and RDFs. I don't see how you could possibly do that with Win7.

If the RDF's are stored in the Program Files subdirectory, wouldn't they be subject to all that virtual stores problems. If SVN is run from within RMIR, would IR be able to see the changes? Or since RMIR did the change at a time not during installation, would these go into virtualstores for RMIR use only?
The changes made to the VirtualStore affects only the user who applied the changes. Think of it as that user's virtual environment, all the programs running within the environment are susceptible to the changes incurred by respective user. You still have access to that directory by the way. So, you can make direct changes, and creating a shortcut is pretty easy if you don't always want to "look" for it.

Now, let's say DH had a login on your computer. They would not see your changes that you created in your environment. In fact, if your drive partiton uses NTFS, they couldn't even have access to the changes without going out of their way to take ownership of your %LOCALAPPDATA% directory.

Personally, I think there's still a need for a mechanism which diverges any personalization for the protocol.ini and the RDFs. That way the users do not have to worry about updates overwriting their past customizations.

Posted: Mon Nov 21, 2011 3:42 pm
by vickyg2003
eferz wrote: The changes made to the VirtualStore affects only the user who applied the changes. Think of it as that user's virtual environment, all the programs running within the environment are susceptible to the changes incurred by respective user. You still have access to that directory by the way. So, you can make direct changes, and creating a shortcut is pretty easy if you don't always want to "look" for it.
I worked with virtual stores a bit in Vista. I haven't seen how it works on 7, so they may have fixed things. But once RMIR makes any changes to the data in Program files, that data is in that darn virtual store. If you delete you RMIR totally and then reinstall it, that virtual data is still there. So now that RMIR allows you to view your RDF's you can see the changes, but woe be to the person looking for the stuff in the Program Files because it may or may not be the same.

As I said, I can't understand how anybody in a hacking mentality like ours could stand to dink around with the JP1 tools in the restricted environment of the Program Files with the Windows restrictions. I want to poke, peek and test without worrying about whether Windows will allow me to get away with it.

Now, let's say DH had a login on your computer. They would not see your changes that you created in your environment. In fact, if your drive partiton uses NTFS, they couldn't even have access to the changes without going out of their way to take ownership of your %LOCALAPPDATA% directory.
Well thats good, because he would be happy to delete any JP1 stuff he was able to find. He hates this hobby.

Posted: Mon Nov 21, 2011 5:38 pm
by eferz
vickyg2003 wrote:I worked with virtual stores a bit in Vista. I haven't seen how it works on 7, so they may have fixed things. But once RMIR makes any changes to the data in Program files, that data is in that darn virtual store. If you delete you RMIR totally and then reinstall it, that virtual data is still there. So now that RMIR allows you to view your RDF's you can see the changes, but woe be to the person looking for the stuff in the Program Files because it may or may not be the same.

As I said, I can't understand how anybody in a hacking mentality like ours could stand to dink around with the JP1 tools in the restricted environment of the Program Files with the Windows restrictions. I want to poke, peek and test without worrying about whether Windows will allow me to get away with it.
I think it is like any environment. You get an understanding of what you can do and can't do. Then you place implements to work around any of the obstacles that you have to deal with repetitively.
Well thats good, because he would be happy to delete any JP1 stuff he was able to find. He hates this hobby.
I don't see why, your hobby keeps you safe and content at home. It's not like the hobby involves you pulling a Linsey Lohan all across town... or does it?

Posted: Mon Nov 21, 2011 5:43 pm
by vickyg2003
eferz wrote: I don't see why, your hobby keeps you safe and contempt at home.
The contempt is his, I on the other hand am quite content. :lol:

Posted: Mon Nov 21, 2011 5:49 pm
by eferz
vickyg2003 wrote:
eferz wrote: I don't see why, your hobby keeps you safe and contempt at home.
The contempt is his, I on the other hand am quite content. :lol:
Doh! I meant content.

Interesting though... you intentionally left out whether or not the hobby involves you running around like Lohan.