RemoteMaster setup.exe: Making install dir read-only

[Barf]

From other threads:

RM/RMIR expects the current/working directory to be the directory that contains RemoteMaster.jar, protocols.ini, digitmaps.bin and a number of other files and directories. It also expects to have full read/write/execute permission to those files and directories.

Windows Vista and Window 7 hates it if an app writes information in the "Program Files" sub folders from an app. "Program Files" is a restricted directory. Any changes to the program files directory after installation go in a hidden data stores area. A normal user can't find them, you even a reinstall can't fix them.

I normally don't recommend installing JP1 programs in the Program Files Folder simply because many of the older programs are not Windows 7 compliant and tend to store information in their home folder.

So I decided to check what was needed to make the program "clean" in this sense. (Not only for Windows 7/Vista: In the Unix/Linux world this has been "good manners" since start of the 1990-ties, "mounting /usr read-only".) To my surprise, code for putting the properties file in a more sane place was, for Windows, already implemented. Fot "other" operating systems, I implemented a fix putting the properties file in the user's home directory, staring with a period, as is the common convention on Unix/Linux. Remains the error output file rmaster.err. I implemented a simple fix, putting it in the "system temporary directory" (java.io.tmpdir), amounts to /tmp on Unix/Linux and %HOME%\AppData\Local\Temp on Windows. Here are the changes:

Code: Select all

Index: RemoteMaster.java
===================================================================
--- RemoteMaster.java	(revision 1077)
+++ RemoteMaster.java	(working copy)
@@ -2916,7 +2916,7 @@
 
       try
       {
-        System.setErr( new PrintStream( new FileOutputStream( new File( workDir, "rmaster.err" ) ) ) );
+          System.setErr( new PrintStream( new FileOutputStream( new File( System.getProperty("java.io.tmpdir"), "rmaster.err" ) ) ) );
       }
       catch ( Exception e )
       {
@@ -2969,9 +2969,15 @@
             {
               dir.mkdirs();
             }
+            propertiesFile = new File( dir, "RemoteMaster.properties" );
           }
-
-          propertiesFile = new File( dir, "RemoteMaster.properties" );
+          else // not Windows
+          {
+            String baseFolderName = System.getProperty( "user.home" );
+            if (baseFolderName != null && !baseFolderName.isEmpty())
+              dir = new File( baseFolderName );
+            propertiesFile = new File( dir, ".RemoteMaster.properties" );
+          }
         }
       }
       PropertyFile properties = new PropertyFile( propertiesFile );

Finally, I wrote an Inno Install script, creating setup.exe file that the Windows users love. Here is the result.

Testing and feedback solicited.

[mdavej]

Excellent work, Barf. It works fine, but I would like to see it assign the proper icon image to the shortcut. We've needed something like this for a long time. Right now, setting up RM or IR is very complicated. I think the ultimate goal should be to include the RDF's, Maps and Images as well and automatically default to the installed RDF and Maps folders. Do you have any thoughts on how to accomplish a truly unified install?

Also, how did you get your RM shortcut to just run RM alone? That's fantastic. I've tried and failed to do that for a long time.

[gfb107]

Barf, why don't you just join the "controlRemote" project at sourceforge? Then you can make code changes and check them in yourself.

I take it building the Inno installer package can be automated? That would be a big improvement over the JET installer.

[Barf]

... I think the ultimate goal should be to include the RDF's, Maps and Images as well and automatically default to the installed RDF and Maps folders. Do you have any thoughts on how to accomplish a truly unified install?

First I tried having maps and rdfs downloaded at the user's request, and installed as a part of the installation. I could not find a clean way to accomplish this, so I gave up, at least temporarily. As an experiment, I just uploaded a new version, which

- contains Maps/Images as well as RDSs, optionally installable in directory Program Files\Common Files\JP1\[rdfs,maps]. (No other location possible.)
- Fixes the icon problem
- Makes file associations optional
- If maps and/or rdfs was installed, a rudimentary properties file will be generated (actually, lines are appended to an existing or nonexisting properties file) so that the user does not have to locate rdf/map files at the first start.

Tell me how you like it.

Also, how did you get your RM shortcut to just run RM alone? That's fantastic. I've tried and failed to do that for a long time.

Hardly "fantastic", just "use the source, Luke".

Barf, why don't you just join the "controlRemote" project at sourceforge?

Will do, thanx.

I take it building the Inno installer package can be automated?

Inno runs fine non-interactively; thus can be integrated in Makefiles or ant-scripts. I have done this before. Even installers run fine non-interactively.

[mdavej]

I haven't forgotten about this. But the latest java update seems to have broken all my java apps. I'll try out your new install when I get java working again.

[xnappo]

Just a note that what I would *really* like for RDFs/Maps is a system where RM-IR:

1. Gets the signature of the remote
2. Searches for a local match
3. Queries Sourceforge for a match
4. Downloads from Sourceforge if no local match was found, or offer to update if there is a newer version.

Obviously a lot of work, but thought I would throw that in while on the subject

xnappo

[eferz]

Just a note that what I would *really* like for RDFs/Maps is a system where RM-IR:

1. Gets the signature of the remote
2. Searches for a local match
3. Queries Sourceforge for a match
4. Downloads from Sourceforge if no local match was found, or offer to update if there is a newer version.

Obviously a lot of work, but thought I would throw that in while on the subject

xnappo

I second that motion!

[gfb107]

That would be a lot of work, and we have no version information in RDF file names to work with.

I have another idea that might be acceptable.

Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).

Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.

For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.

Thoughts?

[eferz]

That would be a lot of work, and we have no version information in RDF file names to work with.

I would think the first step would for you to indicate how you'd like the nomenclature to be. Taking a look at a few files it seems there's already a parse-able format

Code: Select all

30463046 (Cox-URC-7820B JP1.3).rdf

Looks like...

SIGNATURE (Human Readable Name).rdf

It shouldn't be difficult at all to rename all the files with the last date of acceptance.

Code: Select all

SIGNATURE DATE (Human Readable Name).rdf

For example, the above with 11/10/2011 date would be.

30463046  20111110 (Cox-URC-7820B JP1.3).rdf

That would make it simple to use a greater/less than statement on the second word in the filename based on the space delimiter. The logistics would probably require each RDF to exist as a separate downloadable file instead of encapsulating them into one zip archive. But, that would also save in bandwidth usage because of iterative updates.

I have another idea that might be acceptable.

Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).

Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.

For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.

Thoughts?

Seems a lot easier but it sounds like an "all or nothing approach". Wouldn't the unzipping of the files cause it to overwrite all the pre-existing files? I personally would be worried because I had changed quite a few of my RDFs (...or maybe it was protocol.ini) to remove the repeats for Slingbox users.

[xnappo]

Thoughts?

Yes, it would be easy to rename the files to include the version. I think I would just embed the SVN version instead of the date. Still easy enough to parse.

It would also be easy to generate and maintain a list of the current versions so RM-IR could use that as a lookup.

The files are already available as individual files - however I am not sure if there are any restrictions from SourceForge on direct linking to the SVN repository from within a program. I don't think the traffic we generate would be much of a concern...

That said, I have no idea how easy/hard the Java side of this would be.

xnappo

[gfb107]

I would think the first step would for you to indicate how you'd like the nomenclature to be. Taking a look at a few files it seems there's already a parse-able format

Code: Select all

30463046 (Cox-URC-7820B JP1.3).rdf

Looks like...

SIGNATURE (Human Readable Name).rdf

It shouldn't be difficult at all to rename all the files with the last date of acceptance.

Code: Select all

SIGNATURE DATE (Human Readable Name).rdf

For example, the above with 11/10/2011 date would be.

30463046  20111110 (Cox-URC-7820B JP1.3).rdf

That would make it simple to use a greater/less than statement on the second word in the filename based on the space delimiter. The logistics would probably require each RDF to exist as a separate downloadable file instead of encapsulating them into one zip archive. But, that would also save in bandwidth usage because of iterative updates.

We have to be carefull about changing the names of RDF files, as it might cause incompatibilities with other tools that use RDFs, primarily IR. Maybe IR won't have a problem with naming conventions, but maybe it will. I don't know.

Doing it at the individual RDF level is almost building an SVN client into RM.

I have another idea that might be acceptable.

Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).

Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.

For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.

Thoughts?

Seems a lot easier but it sounds like an "all or nothing approach". Wouldn't the unzipping of the files cause it to overwrite all the pre-existing files? I

With this approach I wouldn't unzip at all. The RDFs would be read directly from the .zip file. But, yes, it is sort of "an all or nothing" solution.

An enhancement to this idea would be to have a 'work' folder that is checked for files before looking in the zip file. This is where people could keep custom or under-development files. RM would never replace files in this 'work' folder.

personally would be worried because I had changed quite a few of my RDFs (...or maybe it was protocol.ini) to remove the repeats for Slingbox users.

That sounds like protocols.ini.

[gfb107]

Thoughts?

Yes, it would be easy to rename the files to include the version. I think I would just embed the SVN version instead of the date. Still easy enough to parse.

It would also be easy to generate and maintain a list of the current versions so RM-IR could use that as a lookup.

The files are already available as individual files - however I am not sure if there are any restrictions from SourceForge on direct linking to the SVN repository from within a program. I don't think the traffic we generate would be much of a concern...

That said, I have no idea how easy/hard the Java side of this would be.

xnappo

Looks like pulling files directly out of SVN is pretty easy.

[eferz]

Looks like pulling files directly out of SVN is pretty easy.

Woo hoo!

[Barf]

Embedding a svn-client should not be a very difficult matter. I have been using Netbeans which comes with its own svn-client for example. Googling for "java svn client api" gives several hits.

Mapping of signatures to URLs: Best thing would be to have the signature determine the URL/filename uniquely, without any "readability cruft". This is probably not do-able for practical reasons. So instead a solution with a catalog file, e.g. in XML format, is easily suggested. This provides the mapping from signatures to either svn-Urls or local filenames. Something like:

Code: Select all

<remote-file-mappings>
   <admindata>
  <!-- Version of this file, etc -->
...
    </admindata>
    <remote signature="12345678" rdf="http://controlremote.svn.sourceforge.net/.../long and silly name.rdf" map="http://controlremote..../.../another silly name.map" image="http://controlremote.../imagefile.jpg"/>
... 
     <remote signature="87654321" rdf="http://controlremote.svn.sourceforge.net/.../even longer and sillier name.rdf" map="http://controlremote..../.../yet another silly name.map" image="http://controlremote.../another imagefile.jpg"/>
</remote-file-mappings>

This file should be reside in the svn-repository, with a simple, not changing name, so that a program can download it. As a fallback, it would be sensible to compile the current version into the RM program itself, for fallback when the internet connection is not working. For opimization, the catalog file may be saved to disk between sessions. And/or subject to version updates like rdf files.

And please, please, no versions in file names, it will break "everything". Better to use the facilities svn offers. And no zip files.


So, when the user downloads a remote the following happens. Lets assume that RDF is a local directory, setup as a svn local workarea for RDF files. Pseudocode:

Code: Select all

signature = downloadRemote;

if $RDF/localfile(signature) present 
    status = svn.status($RDF/localfile(signature))
    if status == new_file
        user_message("using a local file not in svn")
    else if status == locally_modified
        user_message("using a locally modified rdf file.)
    else if status == conflicts
        user_message("conflicts between local file and svn detected. Resolve manually.")
    else if status == outdated
       answer = user_query("new version of your RDF file exists. download?")
       if answer == yes
              svn.update(RDF/localfile(signature))
    else if status == ok
       // do nothing
else // no local file present
    exists = svn.file_present(url(signature))
    if exists
         answer = user_query("wanna download rdf?")
         if answer == "yes"
               svn.checkout(url(signature))
    else
         user_message("Outta luck with your remote. Ask the friendly guys at hifi-remote.com for help.")

go on using $RDF/localfile(signature)
...
     

The handling of map- and image files I leave as exercise for the reader.

When the user selects "New image..." the following happens:

Code: Select all

try
    catalog_file = download(catalog_URL)
catch
    // download fails
   catalog_file = compiled_in_fallback;

setup pulldown menu of available remotes according to catalog_file
continue as in the download case

Of course, there should be a user option for disallowing internet downloads completely. Also, there may be an option "check only once per day/week/month/..."

Returning to setup routines, there may be an alterative in the setup program just to create empty directories for RDFs, maps, and images; then later to download on demand.

When it comes to protocols.ini, digimaps.bin,... then ... ...

Should not be too hard to implement this really...

[gfb107]

I suppose including an SVN client in RM wouldn't be a big deal.

If we go down this route, I think we would want to make sure only 'official' or 'released' versions of RDFs, maps, and images ever make it to the trunk. This way RM always looks in trunk for the latest version, and doesn't have to know about any tags or branches.

When putting files that aren't ready for distribution into SVN, a branch should be created (with trunk as the source) where those files are kept and revised until they are ready for release. At that point the branch is merged back into trunk, and would be picked up the next time RM checks for updates.

Using SVN would also allow RM to detect if any unofficial RDFs are being used. Don't yet know if or what we'd want to do in that case, but the capability is there.