Yep, gets my vote

it will work fine on a guest account as long as portapotty doesnt require writing to the registry.

Just a quick note to say there won't be a new version for a few days. Last night I ran into a couple of technical snags when testing some InnoSetup setups and other apps that kick off child processes. I finally worked out a reasonable solution to the problems but I don't have time to finish up the testing, and of course the weekend's here so it's time to take a break from this. :)

I'll upload a new version sometime early next week, assuming no other snags crop up when I get back to the testing.

Hey all,

The redirection of the file system is testing well, but there's a usage issue that I want to bring up and discuss to make sure the way it's working sounds reasonable.

What's happening is the PP-run apps are showing the paths for their directories and files as the real system paths, not the redirected equivalents. So the PP-run apps are giving the impression that you're accessing "C:\Program Files\WikidPad\readme_Wic.txt" or "C:\Documents and Settings\username\Desktop", for instance, when in fact you're being redirected into the portablized file system. In other words, you're really accessing "E:\Portables\Program Files\WikidPad\readme_Wic.txt" or "E:\Portables\Documents and Settings\username\Desktop".

I have to say that even for me and all of the testing I've done so far, it's a bit unnerving to see these directory names pop up. The apps have thus far always only modified the redirected file system, not the real system directories and files. But I always end up starting a non-PP run file browser app to check that no real system directories or files were messed with. And not just because I'm testing. I would be doing this as an end user as well. I think it's because, unlike the registry redirection, you see the path the app is using.

So what do you think? Is this good enough as it stands and just requires some getting used to, or should I burn some time now and look into trying to get the app to use the redirected directory and file names at all times? Or do I need to explain this better before you can decide?

It really sounds good redllar, where is the download link?
Fair enough mate, I personally really don't mind, I mean as long as the real system files remain untouched, it's quite superb
Thanks for the efforts once again!

Hm... as long as it doesn't redirect what it shouldn't redirect...

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?

Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

If so, that would be a little tricky...

The way I understand what redllar wrote, it seems to me pretty logical.
You're accessing a file in C:\ABC\MyDoc.XYZ using a PP-run application, the edited file will be converted to E:\Portables\ABC\MyDoc.XYZ as this is the way it is meant to work, isn't it?
If I run a portable application, I want to have a sort of packaged environment and that's the purpose for me.


You most likely mean PP-run app, am I right?

Well I dare say is not the purpose for most of us, the purpose is to make it *portable*

Ie, if I use a text editor it should be able to start up from a given folder, and all the files and data it requires to run should be launchable from that folder, BUT if I save a document I want and need to be able to save it to any path i choose without having it redirected.

I'm still testing and making a few tweaks as I find apps that are using file system apis I haven't redirected yet, so no download yet.

As far as I've been able to tell, no obvious system directory changes are made, except in ones that aren't being tracked, like Documents and Settings\username\Local Settings\Temp.

I don't think it is. It only redirects changes to "system directories", which I'm defining as the list I previously posted. Mostly it's directories that are normally found in Documents and Settings. Directories like username\Desktop, username\Start Menu, etc.

Right now, if C:\ABC is a "known system directory" (see my list from a previous post) then yes, it will, if the file is to be changed, which means that the app opens it with write or delete access. If the file is only opened for reading purposes, then the path is left alone and the app opens the real file. If it then attempts to overwrite it, the path is changed and the new version of the file is written to the redirected directory. If the file is then ever re-opened, even for reading purposes only, the path is modified since a redirected version of that file exists.

Also right now, if C:\ABC is just a regular user directory, no redirection occurs. Eventually I'll add an inclusion list which will allow us to say "treat C:\ABC as a known system directory," which means access to it would then be redirected as well.

Not if C:\ABC is a normal user directory. Please see my post above.


Yes. Thanks for catching that.

I'm shooting for what you're suggesting, but there's a catch here; the apps that PP should be used with aren't always portable with regards to file sytem use. In other words, the app is hard-coded to read and write data to %userprofile% or some other non-portable directory. So PP redirects those accesses to a directory that is portable. But in doing so it has to redirect all of the app's changes, since it doesn't really know what the app is doing when it asks the system to open a file for write access in %userprofile%. PP doesn't know whether the file is an app config file or an app "user data" file. Maybe later we can "teach" PP to get smart about these sorts of things. But for now the limitation will be to not store your user data anywhere in one of the "known system directories."

Just to narrow it down one bit, "packaged environment" might have sounded a little clumsy as it were ...
I am not saying that every single application should run independently from the operating system. I am pretty aware that this would be hardly possible to achieve.
Nevertheless, a purpose of mine or a purpose of yours .... it's still great to have an application like this made by one person, hat off