Failing to remove files e.g. as in bug 1788986 can result in intermediate state where cleared and non-cleared origin directories are not classified, and this requires recomputing quota usage.

If we always move the cleared ones to a temporary directory (regardless of the background task), then we should be able to remove one main cause of such intermediateness.

Note that this does not completely remove the need to recompute since any non-shutdown crash can also cause incorrect quota usage data.

Failing to remove files e.g. as in bug 1788986 can result in intermediate state where cleared and non-cleared origin directories are not classified, and this requires recomputing quota usage.

Hi Jari, does this look accurate to you? Looking at the code, Gecko knows whether the shutdown cleanup failed and retry the failed cleanup at startup again. So in theory the cleanup failure shouldn't require recomputing.

That said, it could still be problematic if the quota manager can start earlier than the sanitizer. Do you know when exactly it starts?

In any case, this patch should make things better for users since the cleared directories will get UUID formatted names even with the shutdown crash (unless anything blocks the directory move).

(In reply to Kagami :saschanaz from comment #2)

Failing to remove files e.g. as in bug 1788986 can result in intermediate state where cleared and non-cleared origin directories are not classified, and this requires recomputing quota usage.

Hi Jari, does this look accurate to you? Looking at the code, Gecko knows whether the shutdown cleanup failed and retry the failed cleanup at startup again. So in theory the cleanup failure shouldn't require recomputing.

That said, it could still be problematic if the quota manager can start earlier than the sanitizer. Do you know when exactly it starts?

In any case, this patch should make things better for users since the cleared directories will get UUID formatted names even with the shutdown crash (unless anything blocks the directory move).

As far as I can see, quota manager delegates part of the usage tracking to the clients. A typical client caches the usage info to a dedicated data store. When there is any kind of a crash, e.g. during a regular write, the information in the data store may go out of sync and to avoid exceeding the quota, we require the clients to scan their directories at startup. Additionally, quota manager has its own cached clientUsage values which also go out of sync.

If there is a sanitizer which detects and retries a failed cleanup at startup again, then the initial scan could probably be bypassed, on the other hand if this mechanism was guaranteed to run before the origin initialization, the scans would be quick as there shouldn't be anything to scan.

https://hg.mozilla.org/mozilla-central/rev/5c1d58ffd6b7

https://hg.mozilla.org/mozilla-central/rev/8cefd5e2ecaf
https://hg.mozilla.org/mozilla-central/rev/5c6f2b83b3e9