- 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
RemoteMaster setup.exe: Making install dir read-only
Moderator: Moderators
My intention was to
Last edited by gfb107 on Mon Nov 21, 2011 10:06 am, edited 1 time in total.
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Yep - exactly.gfb107 wrote:My intention was toI guess the problem is that Windows doesn't prevent writing to the installation folder (in Program Files), but silently redirects to another, hidden folder?
- 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
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
Well, maybe my changes would work if the installation folder was actually made read-only? That is what this thread is about, after all 
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
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.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.
I would recommend using the %LOCALAPPDATA% instead of %APPDATA% which doesn't need to get copied to servers.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'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.
I agree too.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...
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
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.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?
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
-
vickyg2003
- Site Admin
- Posts: 7104
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
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.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?
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.
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
-
vickyg2003
- Site Admin
- Posts: 7104
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
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.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.
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.
Well thats good, because he would be happy to delete any JP1 stuff he was able to find. He hates this hobby.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.
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.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 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?Well thats good, because he would be happy to delete any JP1 stuff he was able to find. He hates this hobby.
Last edited by eferz on Mon Nov 21, 2011 5:49 pm, edited 1 time in total.
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
-
vickyg2003
- Site Admin
- Posts: 7104
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
Doh! I meant content.vickyg2003 wrote:The contempt is his, I on the other hand am quite content.eferz wrote: I don't see why, your hobby keeps you safe and contempt at home.
Interesting though... you intentionally left out whether or not the hobby involves you running around like Lohan.
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)