I do not think so, if we want to restore the original behavior from bug 1690234 ? That was the objective of having separate mappings, I think.

I do not think so, if we want to restore the original behavior from bug 1690234 ? That was the objective of having separate mappings, I think.

But we first need bug 1705304, no ?
If we just remove NS_ERROR_FILE_FS_CORRUPTED here we can expect increase in storage initialization failures which is something I wouldn't do just before holidays.

To recap my understanding:

• bug 1690234 wanted to explicitly exclude corrupted files from being reported as errors, and only corrupted files
• D108793 changed this inadvertently to include also ERROR_DISK_CORRUPT in the above check
• this patch restores the original intention of bug 1690234

So the initial reason why we did bug 1690234 (initialization failures caused by ERROR_FILE_CORRUPT) is not changed by this patch. And failing as early as possible on `ERROR_DISK_CORRUPT seems reasonable to me, I assume general Firefox operations will be not predictable in this case, anyways. I cannot really see what advantage it would give the user to continue to hammer on a corrupted device (assuming the windows error message means to be a non recoverable problem). Having bug 1705304 would be nice in general, but I do not think it is a prerequisite to do the proposed change back here.

I'd thus think the risk for this change to cause a higher amount of storage initialization failures is low, but if we want to wait with landing after the holidays, we can do that, of course.

I cannot really see what advantage it would give the user to continue to hammer on a corrupted device (assuming the windows error message means to be a non recoverable problem).

Only one file or directory could be corrupted in the file system ?
If we suddenly exclude ERROR_DISK_CORRUPT here we might see a spike in storage initialization failures due to that (We don't have async temp storage initialized yet which tolerates broken origins).
ERROR_DISK_CORRUPT was proposed to be mapped to NS_ERROR_FILE_FS_CORRUPTED in this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1690326#c27 because ERROR_DISK_CORRUPT appeared in telemetry reports for GetDirEntryKind. For example https://bugzilla.mozilla.org/show_bug.cgi?id=1704439#c52
So, at the very least, excluding NS_ERROR_FILE_FS_CORRUPTED here should be tried only experimentally and closely watched after landing the patch.
Anyway, I recommend to split this patch into two patches, One for the mapping change and another for excluding NS_ERROR_FILE_FS_CORRUPTED (if we really want to do that now).

Only one file or directory could be corrupted in the file system ?

I'd expect Windows to be smart enough to use ERROR_FILE_CORRUPT in that case.

The current situation hides ERROR_DISK_CORRUPT from the initialization error processing and I cannot believe that this helps with anything but our statistics via telemetry.

Anyway, I recommend to split this patch into two patches, One for the mapping change and another for excluding NS_ERROR_FILE_FS_CORRUPTED (if we really want to do that now).

We need to do anything only if we want to do it both. Changing just the label of the shared mapping is equally meaningless as the current label, I do not see the point to do just that, at least if we trust Windows to be meaningful when distinguishing DISK from FILE here.

As a side note, [here](https://searchfox.org/mozilla-central/source/dom/system/IOUtils.cpp#250) the current implementation throws the wrong error because of the mapping, although I don't know if the error is ever propagated to a JSPromise reject call.

https://bugzilla.mozilla.org/show_bug.cgi?id=1703801#c171

The Comment about is a report from the error propagation bot, in this code location there are especially many hits in cases where the FS is corrupted.

If we were to go through with this remapping, we could return from the recursion call on NS_ERROR_FILE_FS_CORRUPTED.