RFC: use of Data\settings in PortableApps.com Launcher

24 posts / 0 new

Last post

August 2, 2010 - 10:01am

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

RFC: use of Data\settings in PortableApps.com Launcher

Currently the PortableApps.com Launcher uses the Data\settings directory for two things; the AppNamePortableSettings.ini file and any registry files.

In the current situation, a [DirectoriesMove] line should not be used to move the settings directory because [RegistryKeys] is parsed later, and registry files are in Data\settings, so if you move it they aren't there and no settings will be loaded.

There are two ways of fixing this:

the easy, lazy way: move the execution of the RegistryKeys segment to before the DirectoriesMove segment. This fixes the problem, but there's still some not-neatness about it all.
the more complex but nicer way:
- Move Data\settings\AppNamePortableSettings.ini to Data. This will be an issue for upgrade, and so a simple PostInstallCode macro for PortableApps.comInstallerCustom.nsh can be provided which does Rename $INSTDIR\Data\settings\${APPID}Settings.ini $INSTDIR\Data\${AppID}Settings.ini (think that's right, not tested).
- Move Data\settings\*.reg to Data\registry\*.reg. I can add checking into the Generator so that if you use any %PAL:DataDir%\settings\*.reg files it will remind you to update them to registry rather than settings. Custom installer code would also be provided for a ${MoveFiles} operation.

The second method is more complex, but I think it makes it actually reflect what things should be and are more accurately. Also it frees up the "settings" directory so that it can be moved with impunity. (Currently custom code could potentially also break the [DirectoriesMove] on settings, but I'm less worried about that as developers should know what they're doing with custom code). Gringoloco and I prefer the second method, but it's a significant change, which would require developers to notice it (though it can be detected and they be warned easily) so I thought I'd see what the public reaction was to the idea.

This thread was brought about because of this incident in #portableapps-dev. Please read that log before commenting as it'll help fill out the details and understand why I'm saying this.

(This thread is currently quite fragmented and I haven't put much padding around it because I'm going to bed. See the IRC log or ask questions and I'll try to answer them tomorrow morning (or do I call it this morning? :P), or Gringoloco may too.)

August 2, 2010 - 10:25am

John T. Haller

Offline

Last seen: 6 hours 31 min ago

Joined: 2005-11-28 22:21

Why Move?

Why is it necessary to have the settings directory be moved at all? If we have to use DirectoriesMove and the app is expecting a settings directory and that can't be changed, it could be moved to Data\app\settings instead, back and forth. This requires no changes to any existing apps. And we could have the generator alter any launcher.ini referencing a DirectoriesMove of settings=App\something to app\settings=App\something.

Sometimes, the impossible can become possible, if you're awesome!

August 2, 2010 - 12:01pm

(Reply to #2) #3

Mark Sikkema

Offline

Last seen: 12 years 2 weeks ago

Joined: 2009-07-20 14:55

Why move...

my opinion on this is that, currently it all seems to be a bit of a mess.

We've got PortableApps.comLauncherRuntimeData-AppNamePortable.ini in the Data folder, and AppNamePortableSettings.ini + any registry files in Data\settings folder. While (tell me if I'm wrong) in the old-slyle launchers Data\settings was dedicated to the app it's settings. So we could do it as you propose, but as benedikt93 said:

I'd vote for changing that now, as long as PAL is not that much around. So you don't have mixed up app's and PAL's settings and circumvent your issues.

So, maybe it's better to change and clean stuff up now, instead of ending up having a Data\settings folder just for the 2 or 3 files!

Formerly Gringoloco
Windows XP Pro sp3 x32

August 2, 2010 - 12:04pm

(Reply to #3) #4

John T. Haller

Offline

Last seen: 6 hours 31 min ago

Joined: 2005-11-28 22:21

Should be

I don't think there's anything wrong with reserving the settings folder in Data for our use and having the AppNamePortable.ini (for storing stuff between sessions), runtime stuff and registry stuff in there. And allowing for future expansion of it.

Sometimes, the impossible can become possible, if you're awesome!

August 2, 2010 - 3:11pm

(Reply to #4) #5

Mark Sikkema

Offline

Last seen: 12 years 2 weeks ago

Joined: 2009-07-20 14:55

Could call that: Option 3

What would not be a bad solution! Would keep it simple with changing the PAL code, just need to change the location of the runtime ini('s).

But, loosing Data\settings for the app it's settings ?
What about when a launcher will get converted to PAL, the user's Data back-ups would not be valid anymore.
And we'll be having old-style launchers which mainly have the app settings in Data\settings and PAL launchers which would have theirs in Data\app\settings. Wouldn't it be better to keep the location standard for all portable apps ?

(just some thoughts)

Formerly Gringoloco
Windows XP Pro sp3 x32

August 2, 2010 - 3:16pm

(Reply to #5) #6

John T. Haller

Offline

Last seen: 6 hours 31 min ago

Joined: 2005-11-28 22:21

settings ONLY

This only applies to an app where the settings directory is the one that needs to be moved back and forth. I can't think of any apps that HAVE to have a directory called settings moved around.

We use the settings directory for AppNamePortableSettings.ini and registry entries for every single app we have. App settings themselves are either individual files moved in and out of the settings directory (which causes no issues at all) or whole directories which are kept in Data\OtherDirectoryName like profile or similar.

So, I'm missing what the problem is by saying Data\settings should not ever be moved.

Sometimes, the impossible can become possible, if you're awesome!

August 2, 2010 - 3:24pm

(Reply to #6) #7

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

Launcher Documentation

The documentation says otherwise:

[DirectoriesMove]
These are directories for which to manage portability. They come in the form [directory]=[target location].

The directory is the location of the source directory, relative to the portable data directory (AppNamePortable\Data).

The target location includes the directory you want it to go to, so %PAL:DataDir%\[directory]\*.* gets copied to [target location]\*.*. Environment variable substitions apply.

If the target directory already exists at the start of the process, it will be backed up (to target location-BackupByAppID) and restored at the end.

If you do not wish to save the data but only want to keep a local version safe and throw away any changes, set the source directory to -, so you end up with -=[target location]. If you don’t wish to back up local data, you can use [DirectoriesCleanupForce].

Wildcards are not yet supported.

Example: settings=%APPDATA%\Pub\lisher\AppName

If developers used the exact same example, then they would have a problem here.

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

June 18, 2011 - 2:25pm

(Reply to #7) #8

mzorova

Offline

Last seen: 12 years 3 months ago

Joined: 2008-04-13 12:34

Would be great to have Data OUTSIDE the Code tree

Separating the executable code from the settings files enables two things:

a) using one copy of portable apps code with different user settings
b) using dropbox to sync the portable apps code itself across multiple computers and users without overwriting each individual users settings (I do this)
c) enables carrying the data alone on a USB drive, the code can be installed on all machines thereby saving space on the USB stick

There are probably tons of other reasons you want to keep the code and settings in different trees. The old PortableApps infrastructure understood that and used to support a SettingsDirectory setting that made this clean.

Whoever is running the new installer stuff has clearly decided that this is no longer necessary and mixing the settings and the code into the same directory is the best path forward.

Most OS's have the program executables and individual user settings in different trees => mostly to enable above.

One of these days when I get the time, I will edit the new launcher to support this, but for now, my day job does not allow me the luxury of being able to spend time on this.

June 19, 2011 - 7:22am

(Reply to #8) #9

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Irrelevant

That is nothing to do with this thread.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

August 2, 2010 - 3:49pm

#10

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

Option 2

It depends. Ideally all of the important PA.c-related settings are placed in Data\settings and Data\settings is roped off in the Format (allowing for future expansions if necessary).

I wouldn't be opposed to AppNamePortableSettings.ini being in Data either, so Option 2 has my vote.

EDIT: Option V, Option 3, then Option 2 in order of favor.

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

August 2, 2010 - 3:12pm

#11

prapper

Offline

Last seen: 2 years 7 months ago

Joined: 2008-01-24 17:01

The Third Way Of Fixing This

Chris Morgan a [DirectoriesMove] line should not be used to move the settings directory

Right, so don't use: "settings=".

No:

[DirectoriesMove]
settings=%APPDATA%\Spotify

Yes:

[DirectoriesMove]
settings\Spotify=%APPDATA%\Spotify

Fixed.

August 2, 2010 - 3:24pm

(Reply to #11) #12

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

Hmm...

The main issue, as I've interpreted, is that either there is a directory named settings to be moved, or that the Data\settings directory is moved to a differently named directory (assuming developers use the example in the documentation), so that would work.

Ideally, developers shouldn't touch the Data\settings directory for anything other than registry entries and service details (if that is ever supported). All directories and files to move should be in Data.

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

August 2, 2010 - 3:37pm

(Reply to #12) #13

prapper

Offline

Last seen: 2 years 7 months ago

Joined: 2008-01-24 17:01

Whatever

Whatever the documentation says, the settings directory shouldn't be moved. Move/copy stuff in and out of it.

EDIT: Sorry, the post title wasn't meant in the dismissive way

August 2, 2010 - 3:37pm

(Reply to #13) #14

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

Just Confusing

I'm not doing it personally, but someone who uses the docs could get confused. That's why I'm noting it.

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

August 2, 2010 - 3:47pm

#15

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

Option V

Building off of previous options, I'd like to see this:

Data\settings - PA.c settings + anything that the launcher deals with specially (registry, services)
Data - everything else (files/directories moved)

That would be ideal, I would think. The reason I don't think files should be in settings - Data\settings should attempt to remain PA.c exclusive.

(Sidenote: do we know of any pre-releases or official releases impacted? development testers are warned that things might break anyway)

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

August 2, 2010 - 4:21pm

#16

Gremlin

Offline

Last seen: 4 weeks 1 day ago

Joined: 2010-07-02 04:48

I personally have

I personally have Data/userfiles to move around. Thus I do not need to touch Data/settings.

Cheers

Gremlin

August 2, 2010 - 7:37pm

#17

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Comments

First of all, with [DirectoriesMove] the target directory is a full path, including the target directory name. So app\settings=%PAL:AppDir%\Something could actually be done like this: data=%PAL:AppDir%\Something\settings. Also because of the next paragraph using app\ would be a bad idea.

I personally like to try to avoid using subdirectories with [FilesMove] and [DirectoriesMove]; with settings\* it's alright, but any other thing will run into issues unless the directory is created in DefaultData - you can't create a file or directory in a directory that doesn't exist, so I prefer to steer clear of them altogether as far as is reasonable. It's not practical to implement lots of warnings like this in the Generator though, there's no adequate way of telling the user about such things. I think I'll put lots of warnings and errors and validators and interesting things in my Development Toolkit though... if I ever get enough spare time to continue making it more useful.

With regards to the example in the documentation for [DirectoriesMove], I'd forgotten about that and must fix that. I don't think it's ever actually been compatible with [RegistryKeys], just I didn't realise that until after I'd written that into help.html, and I just transferred all that sort of content into the manual directly.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

August 3, 2010 - 9:05am

(Reply to #17) #18

thesupremecommander

Offline

Last seen: 10 years 10 months ago

Joined: 2010-07-03 14:58

DefaultData

IMO, DefaultData = Data - (runtime stuff). Everything should be ready to be transferred (default option files, registry keys, etc.) on launch if it doesn't exist.

However, other developers may not do that, depending on the app they create (unpredictability is a big issue there).

My Dev Tests: ~ KeePass Pro Portable (awaiting .NET directory) ~ FreeCol Portable (needs testers)

"... proving to everyone that we are operating on Valve Time..." - us

August 3, 2010 - 9:35am

(Reply to #18) #19

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Minimal

DefaultData is purely the initial content for Data. What the developer does with it is up to them, but keeping it as empty as possible (or reasonable) is advisable in my opinion, as it makes the package smaller (generally a bit, occasionally a lot) and leaves the program to set up settings how it wants to, meaning you don't get your settings, settings how you like them, or the default settings from an older version, where the defaults have changed.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

August 3, 2010 - 10:15am

#20

Simeon

Offline

Last seen: 8 years 11 months ago

Joined: 2006-09-25 15:15

I never understood what the Data/settings folder was for if everything that was in it could have been inside the /Data folder.

Just to make sure I understood the problem:
If an app has settings files, they can be moved without moving the /Data/settings folder -> no problem.
If an app has a folder called anything else but "settings", it can be moved without moving the /Data/settings folder -> no problem.
If an app has a settings folder called "settings" and registry data files and I move the /Data/settings folder to the app folder I have a problem. As a solution, couldnt we (=the dev of the app in question) just create a folder called /Data/settings/settings and move that one to the app folder?

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

August 3, 2010 - 6:50pm

(Reply to #20) #21

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Not quite

The target directory is the full path, so the source directory name doesn't matter - this means you can move Data\foo to App\AppName\settings with foo=%PAL:AppDir%\AppName\settings. That will move Data\foo\*.* to App\AppName\settings\*.*. There is no necessity to move the directory "settings". So really there's no need to change this, it's purely to make it feel better. I quite agree with you about the files in Data/settings; I think we used to just not put any files in Data without their being in a subdirectory, but I'm not sure why that is. I definitely don't now.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

August 4, 2010 - 5:08am

(Reply to #21) #22

Simeon

Offline

Last seen: 8 years 11 months ago

Joined: 2006-09-25 15:15

Then I could go and put settings=%PAL:AppDir%\AppName\settings and it copies everything from /Data/settings/settings to %PAL:AppDir%\AppName\settings, right?
That way the problem you described in the main post would be solved as all the other files would remain inside the /data/settings folder. I can see that this would be a "not so nice"-solution as there is this second settings folder...but thats still the way I'd go.

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

August 4, 2010 - 7:27pm

(Reply to #22) #23

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

settings=%PAL:AppDir%\AppName\settings copies everything from Data\settings\*.* to %PAL:AppDir%\AppName\settings\*.*. The source is relative to Data, not settings, and the target is a full path and does not have the source appended to it.

settings\settings=%PAL:AppDir%\AppName\settings would do that. But it'd be neater to do something like data=%PAL:AppDir%\AppName\settings. Or if I were to move Data\settings\*.reg to Data\registry\*.reg and Data\settings\AppNamePortable.ini to Data\AppNamePortable.ini, then the settings directory would have no problems with being moved. It's just currently it's somewhat a "reserved directory".

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

September 15, 2010 - 5:20pm

#24

Devo

Offline

Last seen: 1 year 1 week ago

Joined: 2007-09-04 14:55

Has this been resolved?

I'm working on upgrading MediaMonkey portable and some of the other apps I created. I've been trying to follow the discussions on the PortableApps Format regarding the location of settings. I know that registry files go in Data/settings, and that is all that should go in Data/settings. My question is, is there a location that all the other files should be placed? There isn't really a mention of it in the Format Specifications.

My personal preference would be to place the files within Data/AppData and place the registry entries within Data/settings. I think this definitely needs to be defined somewhere in the Format Specifications. Any opinions on where files (anything other than registry files) should be placed?

You are here

RFC: use of Data\settings in PortableApps.com Launcher

Please Help Support Us

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com

You are here

RFC: use of Data\settings in PortableApps.com Launcher

Please Help Support Us

User login

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com