Bug? Portable Firefox deletes normal Firefox AppData dir if it's a junction

As discussed, this appears to be an issue on the part of Windows as a simple check for existence of the directory and whether there are files in it returns an incorrect answer. As an admin, you should not be using junctions within the APPDATA hierarchy. If you as a user were to install standard Firefox on that machine, it would similarly mess up. Your admins, when they setup your distribution, did not heed the Microsoft's usage recommendations, the first two points of which are: (1) Use NTFS ACLs to protect junction points from inadvertent deletion. (2) Use NTFS ACLs to protect files and directories that are targeted by junction points from inadvertent deletion or other file system operations.

Unfortunately, there's not much we can do to fix a poorly-setup configuration like this. We use an unaltered copy of the official Firefox builds with Mozilla's permission which does not permit us to alter pieces within Firefox. So, we have to clean up after it closes.

Hmm, you're right. I guess I just never heard of them before. Either way, it seems they don't work right if an app checks to see if a directory is empty and Windows says it is when it's a junction with files in it (which is why there are all those warnings).

I get the impression that you may not be a fan of junctions ... Even if this case, they do work very solidly in Windows/NTFS; the main problem is just that MS didn't provide good ways for detection/removal and RMDIR handles them poorly. Aside from that, I've never seen any scenarios where junctions did not work correctly with Windows APIs due to them being junctions (I have seen some issues which occur with folders - such as locking -- happen for junctions as well). As for using them in APPDATA, I've never seen any recommendations for or against using junctions there... and while it may not be a traditional approach on Windows, this is done frequently by many many people (usually for storage reasons or to make scripted backups easier). I have seen many cases of this on the web, including in a technet.microsoft.com thread. And similar usage is quite common under Linux systems where MS took the idea from

While I can't speak for PA.c Platform/Launcher (not sure if those are still using NSIS), I would hope that those still support per-app settings (such as allow multiple instances/disable splash) as those settings are important to many in the community. Even if the new setup were in C++/Java/etc, I don't think it would be too bad... and I would be more than willing to help if you are open-minded towards the idea.

I think the problem we've run into here is literally just in the cleanup method and can be handled safely without a lot of changes. In my previous post, I was suggesting to have a flag which would just bypass the need to detect/handle linked dirs entirely and instead just let the user have an INI setting for it (e.g. "change it at your own risk").

And while you could certainly detect linked dirs and then refuse to run, I would hope that you wouldn't do it that way... At the point where you have added the detection logic, you would have everything you need to fix the issue and it would be very trivial to do so. Refusing to run after detecting junctions would only hurt end users and for no real reason or benefit.

If you were going to add detection logic, it would be just as easy if not easier to avoid the problem altogether. Here is a psuedo-NSIS snippet showing this with the function you had linked to.

;-- sample using the function you linked to
${IsSoftLink} "${Path}" ${outVar} 
StrCmp $outVar 1 skipdelete
;-- delete empty folders like usual

:skipdelete
;--continue cleanup

If that doesn't work for you (I had to tweak it slightly to get it working under nsis v3.0b0), then here is another version that should work with less dependencies and technically should be slightly faster due to more focused attribute checking (although we're talking milliseconds and I doubt the difference would be noticeable):

;--------------------------------------------------------------------------
; -- Usage:
;--    ${IsLinkedDir} "$Path" $OutputVar
;-- Returns (OutputVar):
;--   -1 - Encountered an error (such as invalid path/does not exist)
;--    0 - Path is NOT a junction/symbolic link
;--    1 - Path IS a junction/symbolic link
;--------------------------------------------------------------------------
Function IsLinkedDir
	!define IsLinkedDir `!insertmacro IsLinkedDirMacro`

	!macro IsLinkedDirMacro _PATH _RESULT
		Push `${_PATH}`
		Call IsLinkedDir
		Pop ${_RESULT}
	!macroend
	
	Exch $0
	System::Call 'kernel32::GetFileAttributes(t r0)i .r1'
	StrCmp $1 -1 error
	IntOp $0 $1 & 0x0400
	IntCmp $0 0 +2
	StrCpy $0 1
	goto end

	error:
	SetErrors
	StrCpy $0 $1

	end:
	Exch $0
FunctionEnd

Anyway, I hope I'm not coming off as argumentative or disagreeable. As you already pointed out in your earlier posts, there are other ways to do this including ACLs. I think there is also a way to have the non-portable FF install look for its profile data in another folder (but IIRC, this may require manual setup), so that in theory you could get them to play nice that way. There may be other methods too.

I'm just trying to point out another usage pattern and an easy way to allow it. I think fixing it here has several advantages, such as being less complicated, being independent of one's permissions to change ACLs, and potentially allowing easy automation/scripting for profile setup tasks).

Either way, I like portableapps a lot and have a lot of respect for all the time and work it must take you to do all of this. And for that I would like to say, Thank You! For any of the rest in this thread, I am happy to help if I can and you are open to it, but if you have already made up your mind then it is what is.

Thank you for your answer.
For now I also take Palemoon portable with me because it doesn't write to the Firefox AppData, of course. But you are right, Palemoon also writes to the local AppData.
But I am still concerned that portable apps write to the AppData folder instead of only to the Temp folder.