folder in C:\Users\XXX\AppData\Local\Moonchild Productions\Pale Moon\palemoon

[lavabo]

palemoon portable keeps creating this empty folder at
C:\Users\XXX\AppData\Local\Moonchild Productions\Pale Moon\palemoon

how do I stop this to leave no trace on C ?

[New Tobin Paradigm]

You can't.

[RoestVrijStaal]

@lavabo

Follow these instructions first: viewtopic.php?f=3&t=49

Are you sure you use the Portable edition and not the Zip-ed edition?

[New Tobin Paradigm]

He doesn't need to include info. I know what he is talking about and answered him.

[RoestVrijStaal]

He doesn't need to include info. I know what he is talking about and answered him.

Well, mind to share with the rest of us what's he talking about?

A portable edition creating a folder in a non-temporary-folder within the %userprofile% directory structure is...abnormal imho.

The idea of a portable edition is to keep the system untouched, as in writing only in the folder and subfolders where the portable program is stored.

[New Tobin Paradigm]

I am aware of that. The portable version, stub aside is identical to the other release binaries. Also, the stub is not a sandbox. This relates the fact that as the actual binaries are not specially created for the portable version it contains the Updater and ShellService of which CAN make modifications on the host machine. Specifically, the updater code requires a place to stage any updates for the application and has no concept of knowing that this is a portable copy and shouldn't write to it's default location of %localappdata% for such things and even when an update isn't in progress it preps those locations on startup. It doesn't do anything with %appdata% aka Roaming Application Data because the stub provides it a direct path for the profile to use so the Profile Manager doesn't get involved past loading the profile at the location provided.

Save for setting a few preferences and issuing what is essentially a -profile command line argument plus a handful of other arguments and setting environmental variables for invoking the actual application executable.. It doesn't do anything much else aside from a kickass splash screen.

It is portable in that it is directed to store and use a profile relative to its self but besides that it is just standard Pale Moon with every feature and function a normal installation would have because the actual application binaries ARE EXACTLY THE SAME FILES.

Oh you might argue that that is not portable in the PortableApps.com sense but the definition of portable is not absolute. In any case, there is no way to resolve this without creating a special build JUST for the portable version and at that rate it is just isn't worth the extra release engineering not to mention code changes to accomplish this thus far.

NOW TELL ME.. Did my long involved explanation tangibly change anything for you?

[Frasier]

NOW TELL ME.. Did my long involved explanation tangibly change anything for you?

Nope, but it did confirm my suspicions of the reason for it's existence.

Thanks much.

[Isengrim]

Is it feasible and/or worthwhile to add a command line flag to tell the application to use a different folder than %localappdata%?

[New Tobin Paradigm]

No.

[Moonchild]

It might be an option to make portables exclude the shellservice and updater but that will mean more release engineering and most likely more people not updating the browser when they should, so I'm apprehensive about that concept.

[Herb_]

Why not run it with a batchfile if it is a real problem for users?

some_path\Palemoon-Portable.exe
rd %userprofile%\appdata\Local\Moonchild Productions /s/y

[Moonchild]

I've considered (a long time ago already, actually) the option to remove files and folders on the host system after running (from the portable shell .ini file which allows that natively) to answer the people who would like it to run "stealth" even though that's not the portable's design, but realized that that can't be done because people will also use the portable alongside installed versions of the browser and that would be disastrous for the installed version. It's always better to not be destructive in that way.

The same applies to using a batch file for it -- it's risky.

(semi-offtopic) As an aside, one has to wonder why users want to run it "under the radar" -- if this is bringing USB sticks into your place of work or something you have to realize that that is usually against policy for some very good security reasons and it might cost you your job if you run unsanctioned software on company networks.

[RoestVrijStaal]

@New Tobin Paradigm & @Moonchild

Thanks for your clarifications.