New: DiskMon (Feb 02, 2023), Platform 24.0 (Jan 30, 2023)
450+ real apps (49GB), 1 billion downloads, Please donate.
PicPick Portable v4.2.0
I think there is a bug in the way PicPick Portable has been made into a PortableApp. As far as I am aware a properly constructed PortableApp should not be writing anywhere but in the PortableApp's own directory structure on the flash drive. However, on launching PicPick Portable it creates a folder at the following path:
C:\Users\UserName\AppData\Roaming\PicPick
If this is a bug it needs fixed.
Hope this helps.
This is by design. The folder is removed on exit.
PicPick itself is not fully portable and will normally leave things behind. As a closed source app, we can't adjust that. What we can do is prepare the machine before running (backing up any local settings if there are any and then moving the portable version's files to that location) and clean up when it's done (move the portable's settings back to within the PicPickPortable\Data hierarchy and restoring the local version's settings if there are any).
Okay, fair enough John. However, the folder isn't removed on exit (nor on system re-boot come to that) - but I appreciate PortableApps might not have control of that.
The launcher is correctly configured to remove it on exit. If it isn't that means PicPick is still running (it runs from the system tray even after you select Quit from the UI) or that the folder is locked by another process within Windows. I've verified that after you right-click the system tray and select Exit that the process closes and the folder is removed on my PC (Windows 10 Pro x64).
Okay John. On my system Win7 Pro. SP 1 x64 the folder remains even on exiting PicPick from the System Tray (which I always do anyway). I guess that means the folder is locked. It's a minor niggle - nothing more.
If you delete the folder in Explorer, does it come back and then get properly removed when you run PicPickPortable.exe and then exit via the system tray? Be sure not to have the folder open in Explorer on exit, of course.
Hi John,
I did the following.
1) Delete the PicPick folder that already exists (that gets left behind on exit of PicPick).
2) Launch PicPick - this recreates the folder just deleted.
3) Using IObit Unlocker check to see if folder is locked - reports folder not locked.
4) Just to double-check this try and delete the folder, even though PicPick is still active in the System Tray - result, folder deletes without problems, which means that it isn't locked.
5) Exit PicPick from the System Tray. (Folder already manually deleted in previous step).
Having done that to check if the folder is locked or otherwise. Now do the following:
1) Launch PicPick. It creates a new folder.
2) Check if folder is locked using IObit Unlocker. Result, folder not locked.
3) Exit IObit Unlocker just in case having the folder listed in there puts a lock on the folder.
4) Exit PicPick from the System Tray. Result, folder not deleted.
5) Check if folder is locked using IObit Unlocker. Reports folder not locked.
6) Manually delete the folder. Occurs without issues even though the folder is still listed in IObit Unlocker (proving that Unlocker isn't locking the folder itself.)
Then I repeated all the steps in the second set of steps above without using IObit Unlocker at all. Result was that on exit of PicPick at the System Tray the folder still gets left behind.
So all in all seems just to be the case that PicPick just isn't deleting the folder on my system.
P.S. I just discovered that PicPick creates two such folders per launch as follows:
C:\Users\UserName\AppData\Roaming\PicPick
C:\Users\All Users\PicPick
The newly discovered folder in All Users likewise does not get deleted on exit of PicPick from the System Tray. Again I checked this folder with the same steps above with the same results.
Visit the Community page
Join our forums