Add mappings for NS_ERROR_MODULE_WIN32 errors generated from nsLocalFileWin.cpp
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
People
(Reporter: sg, Unassigned)
References
(Blocks 7 open bugs)
Details
(Keywords: leave-open)
Attachments
(9 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
The NS_ERROR_MODULE_WIN32 errors actually generated from nsLocalFileWin.cpp should eventually be mapped to platform-agnostic error codes.
Comment 1•4 years ago
|
||
One candidate error code to be added is 0x570 ERROR_FILE_CORRUPT
. We already have NS_ERROR_FILE_CORRUPTED
, but we use it probably at a higher level of abstraction (reading a file whose content we don't understand wrt the expected content, like jar). As 0x570 ERROR_FILE_CORRUPT
needs probably different actions (it is a strong indicator of file system corruption) than dealing with a file we might have wrecked ourself, I'd propose a new NS_ERROR_FILE_OS_CORRUPT
. Ideas for a better naming are welcome!
Comment 2•4 years ago
•
|
||
While NS_ERROR_FILE_CORRUPTED already exists, it indicates most of the times more a parsing problem of a given file format.
But Windows ERROR_FILE_CORRUPTED signals a malfunctioning or corrupted file system at OS level, thus we translate it to the new
NS_ERROR_FILE_FS_CORRUPTED.
There seems to be no suitable errno under POSIX to map here.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 5•4 years ago
|
||
WIN32(0x45D) is ERROR_IO_DEVICE seems to happen in the wild, too.
Comment 6•4 years ago
|
||
Comment 8•4 years ago
|
||
bugherder |
Comment 9•4 years ago
|
||
Looking at what I can map ERROR_DISK_FULL in ConvertWinError I was wondering, if ERROR_DISK_FULL and/or ERROR_HANDLE_DISK_FULL should really map to NS_ERROR_FILE_TOO_BIG, which sounds meaningful to me only in case we are writing a (large) file. And the only place we intercept NS_ERROR_FILE_TOO_BIG seems to deal with 32Bit limitations while reading, not with the disk full case.
Comment 10•4 years ago
|
||
The code which depends on the old generic NS_ERROR_MODULE_WIN32 mapping needs
to be updated too.
Depends on D113505
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Comment 13•4 years ago
|
||
0x1E3 seem to have no current mapping in official documentation ? And in winerror.h we only see:
#define MK_E_UNAVAILABLE _HRESULT_TYPEDEF_(0x800401E3L)
whatever MK_E_UNAVAILABLE
means (what I read in internet talks about marshaling to office?).
Comment 14•4 years ago
|
||
Comment 15•4 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #13)
0x1E3 seem to have no current mapping in official documentation ? And in winerror.h we only see:
#define MK_E_UNAVAILABLE _HRESULT_TYPEDEF_(0x800401E3L)
whatever
MK_E_UNAVAILABLE
means (what I read in internet talks about marshaling to office?).
I don't think MK_E_UNAVAILABLE has to do with the error. According to net helpmsg 483
, the error message for Win32 error code 483 (0x1E3) is "The request failed due to a fatal device hardware error."
Comment 16•4 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #13)
And in winerror.h
Obviously this is not an official Microsoft repo. I found
//
// MessageId: ERROR_DEVICE_HARDWARE_ERROR
//
// MessageText:
//
// The request failed due to a fatal device hardware error.
//
#define ERROR_DEVICE_HARDWARE_ERROR 483L
in my local Windows SDK installation.
Comment 17•4 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #16)
#define ERROR_DEVICE_HARDWARE_ERROR 483L
in my local Windows SDK installation.
Thanks for looking that up! That sounds much more plausible, indeed.
Comment 18•4 years ago
|
||
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
bugherder |
Comment 21•3 years ago
•
|
||
There are some new Windows errors. hurray!
Code | Meaning | Where |
---|---|---|
0x12 | ERROR_NO_MORE_FILES | GetNextFile , this might be something we need to handle/expect? |
0x1 | ERROR_INVALID_FUNCTION | GetDirectoryEntries , not sure but we might try to invoke GetDirectoryEntries on a directory that vanished in the meantime? |
0x5AA | ERROR_NO_SYSTEM_RESOURCES | Sounds not very actionable, but is definitely fatal |
0x1129 | ERROR_REPARSE_TAG_INVALID (The tag present in the reparse point buffer is invalid.) | GetDirectoryEntries |
0x17 | ERROR_CRC Data error (cyclic redundancy check). | CopyTo From what I read, it is another form of saying "filesystem corrupt" |
Comment 22•3 years ago
|
||
We should map also:
ERROR_INVALID_NAME
- 123 (0x7B)
- The filename, directory name, or volume label syntax is incorrect.
Comment 23•3 years ago
|
||
Updated•3 years ago
|
Comment 24•3 years ago
|
||
Comment 25•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 26•3 years ago
|
||
The error 0x1129 ERROR_REPARSE_TAG_INVALID
now also appeared in Bug 1702422 Comment 83 for the first time.
Comment 27•3 years ago
|
||
The error 0x571 ERROR_DISK_CORRUPT
appeared in Bug 1704439 Comment 52 for the first time. The Microsoft docs says "The disk structure is corrupted and unreadable.", so maybe it could be mapped to NS_ERROR_FILE_FS_CORRUPTED
.
Comment 28•3 years ago
|
||
The error 0x571 ERROR_DISK_CORRUPT
also appeared in Bug 1702422 Comment 83 for the first time.
Comment 29•3 years ago
|
||
The error 0x1129 ERROR_REPARSE_TAG_INVALID
appeared in Bug 1720080 Comment 52 for the first time.
Comment 30•3 years ago
|
||
Updated•3 years ago
|
Comment 31•3 years ago
|
||
Comment 32•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 33•3 years ago
|
||
The error 0x510 ERROR_CONTENT_BLOCKED
appeared in Bug 1702421 Comment 78 for the first time.
Comment 34•3 years ago
|
||
Comment 35•3 years ago
|
||
Updated•3 years ago
|
Comment 36•3 years ago
|
||
bugherder |
Comment 37•2 years ago
|
||
Comment 38•2 years ago
|
||
Comment 39•2 years ago
|
||
bugherder |
Comment 40•2 years ago
|
||
The severity field for this bug is relatively low, S4. However, the bug has 5 See Also bugs.
:jkrause, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 41•2 years ago
|
||
(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #40)
The severity field for this bug is relatively low, S4. However, the bug has 5 See Also bugs.
:jkrause, could you consider increasing the bug severity?
The see also here keep just track where we've seen this Windows error the first time. Having or not having this mapping does not change anything for the end-user.
Comment 42•2 years ago
|
||
Comment 43•2 years ago
|
||
Comment 44•2 years ago
|
||
bugherder |
Comment 45•2 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jkrause, maybe it's time to close this bug?
For more information, please visit auto_nag documentation.
Comment 47•10 months ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Description
•