Bugzilla

This patch does now delete the entire content of the profile directory. And once we solved bug 1715742, we can be pretty sure to have just an empty profile directory left before unlocking. But there is still a small chance for a race with another starting instance left, as we cannot delete the profile directory itself before unlocking it. I see basically three paths here:

1.  If bug 1715742 is solved, we can downgrade the root directoy's `NS_ENSURE_SUCCESS_VOID(rootDir->Remove(true));` to be non-recursive (as it is not needed any more as a fallback). This should reduce the risk of doing harm to another instance that just started to put files there (what would make the removal just fail).
2. To be 100% sure to not cause any problems, we could just leave the empty directory in place. It feels not very clean, but the overhead on disk is minimal and there is no sensitive data left, anyway.
3. We could find a different place for the lock-file (outside the profile directory). I assume this to be non-trivial in terms of finding a "good" place and name for it, but I might be wrong.

I would opt for 1.) (and maybe add it as todo there).

This patch does now delete the entire content of the profile directory. And once we solved bug 1715742, we can be pretty sure to have just an empty profile directory left before unlocking. But there is still a small chance for a race with another starting instance left, as we cannot delete the profile directory itself before unlocking it. I see basically three paths here:

1.  If bug 1715742 is solved, we can downgrade the root directoy's `NS_ENSURE_SUCCESS_VOID(rootDir->Remove(true));` to be non-recursive (as it is not needed any more as a fallback). This should reduce the risk of doing harm to another instance that just started to put files there (what would make the removal just fail).
2. To be 100% sure to not cause any problems, we could just leave the empty directory in place. It feels not very clean, but the overhead on disk is minimal and there is no sensitive data left, anyway.
3. We could find a different place for the lock-file (outside the profile directory). I assume this to be non-trivial in terms of finding a "good" place and name for it, but I might be wrong.

I would opt for 1.) (and maybe add it as todo to bug 1715742).

This patch does now delete the entire content of the profile directory before unlocking. And once we solved bug 1715742, we can be pretty sure to have just an empty profile directory left before unlocking. But there is still a small chance for a race with another starting instance left, as we cannot delete the profile directory itself before unlocking it. I see basically three paths here:

1.  If bug 1715742 is solved, we can downgrade the root directoy's `NS_ENSURE_SUCCESS_VOID(rootDir->Remove(true));` to be non-recursive (as it is not needed any more as a fallback). This should reduce the risk of doing harm to another instance that just started to put files there (what would make the removal just fail).
2. To be 100% sure to not cause any problems, we could just leave the empty directory in place. It feels not very clean, but the overhead on disk is minimal and there is no sensitive data left, anyway.
3. We could find a different place for the lock-file (outside the profile directory). I assume this to be non-trivial in terms of finding a "good" place and name for it, but I might be wrong.

I would opt for 1.) (and maybe add it as todo to bug 1715742).