If you read
Or people use the constants even if they are not defined, as for example, nsIZipWriter, http://developer.mozilla.org/en/docs/nsIZipWriter, see the bottom example code.
Or people recode the constants over and over and over again, see for example
Did they copy them correctly? Just more lines of code to test.
The values seem to be
612 /* Open flags */
613 #define PR_RDONLY 0x01
614 #define PR_WRONLY 0x02
615 #define PR_RDWR 0x04
616 #define PR_CREATE_FILE 0x08
617 #define PR_APPEND 0x10
618 #define PR_TRUNCATE 0x20
619 #define PR_SYNC 0x40
620 #define PR_EXCL 0x80
I'm not sure that nsIFile is the right place for them, since they're related to IO rather than attributes of a file. Perhaps they'd be better suited on one of the stream interfaces?
They could be replicated at the highest points in the type tree where they are used, including nsIFile.
Now octal literals are deprecated, this would be really helpful.
(In reply to comment #3)
> Now octal literals are deprecated, this would be really helpful.
Sorry, I was talking about permissions and not flags, but this seems to be the same problem.
Created attachment 821474 [details]
I am trying to handle I/O errors during the saving of an attachment of a message
I just realized that in the whole operation of thunderbird, saving an attachment to native file system is one of the few places (maybe only?)
in TB where the user (and TB) needs to deal with
the native platform's file system directly, and handle the I/O error encountered during the operation gracefully and the nature of such error
needs to be propagated to the user for subsequent handling.
("Aha, I forgot to disable write-protection on the USB memory stick" is one example.)
In other operations, TB can deal with abstracted upper-level objects such as
e-mail message, e-mail folder, and remote mail servers that talk protocols defined by RFCs, etc. (Only messy GUI to show the message in intelligible manner to the user and to let user compose e-mail message are outside the scope of RFCs, and the saving of an attachment of operation is one of such activities.)
Anyway, in trying to handle the I/O errors and to show the error encountered in an information-preserving manner so that the user can take a proper action,
I was made aware that the basic I/O error codes and other information that are
So I searched bugzilla and came to this article.
So my understanding of the discussion here is that
we should put something like in the attachment to a system-wide visible
What file should that be?
We have waited far too long for this to happen, haven't we?
Hmm, this type of requests have been very popular everywhere, I suppose.
I just found out
Bug 757351 - Sync uses deprecated octal literals
which discusses the following:
It seems there are duplicate efforts everywhere :-(
Perfect is the enemy of good. I think we better publicize a few such solutions and see
what would be better (not the perfect choice).
To be honest, I have no idea what is the right solution for
say, the use of such symbolic values in,
PS: whichever file that catches the best attention among the developers would be useful...