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.
- 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
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.)
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
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!
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:
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
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!
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
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!
The documentation says otherwise:
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
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.
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
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
Right, so don't use: "settings=".
No:
Yes:
Fixed.
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
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
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
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
I personally have Data/userfiles to move around. Thus I do not need to touch Data/settings.
Cheers
Gremlin
First of all, with [DirectoriesMove] the target directory is a full path, including the target directory name. So
app\settings=%PAL:AppDir%\Somethingcould actually be done like this:data=%PAL:AppDir%\Something\settings. Also because of the next paragraph usingapp\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
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
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
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
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
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
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
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?