Closed
Bug 38122
Opened 25 years ago
Closed 15 years ago
eliminate nsFileSpec and nsIFileSpec
Categories
(Core :: XPCOM, defect, P1)
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: warrensomebody, Unassigned)
References
()
Details
(Keywords: arch, helpwanted)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
dougt
:
review+
bryner
:
superreview+
|
Details | Diff | Splinter Review |
Now that we have nsIFile, we should eliminate all the old nsFileSpec stuff:
http://lxr.mozilla.org/seamonkey/ident?i=nsFileSpec
A lot of this is changing:
nsFileSpec fs(path);
to:
nsCOMPtr<nsILocalFile> fs;
rv = NS_NewLocalFile(path, getter_AddRefs(fs));
and changing the parameter types from nsFileSpec& to nsIFile*.
Also, we should change the functions in xpcom/io/nsIFileStream.h (e.g.
NS_NewTypicalInputFileStream) to the new functions in
netwerk/base/public/nsIFileStreams.idl (e.g. NS_NewLocalFileInputStream).
Help on this one greatly appreciated.
Reporter | ||
Updated•25 years ago
|
Keywords: helpwanted
Updated•24 years ago
|
QA Contact: leger → kandrot
this is an interesting bug.
Keywords: arch,
mozilla1.0
Comment 2•24 years ago
|
||
Comment 3•23 years ago
|
||
I'll take this bug as part of the nsIFIle stuff i'm doing.
I am also working on getting rid of uconv from io.
FileSpec is dependent on uconv nsIFIle is not now.
Assign this bug to me.
thanks
--pete
Assignee: nobody → petejc
Updated•23 years ago
|
Priority: P3 → P1
Comment 6•23 years ago
|
||
Ok, nsFileSpec is used massively all over the place . . .
So this will need to be done in safe step by step stages.
First thing i will do is comment all of the API clones that are in nsIFileSpec
and change over all of the accessors to use nsIFile.
--pete
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 7•23 years ago
|
||
I think we will have to future this for now . . .
--pete
Target Milestone: mozilla0.9.9 → Future
Attachment #129044 -
Flags: superreview?(bryner)
Attachment #129044 -
Flags: review?(dougt)
Comment 9•21 years ago
|
||
Comment on attachment 129044 [details] [diff] [review]
remove unnecessary xpcom_obsolete references (checked in)
great!
Attachment #129044 -
Flags: review?(dougt) → review+
Comment 10•21 years ago
|
||
Comment on attachment 129044 [details] [diff] [review]
remove unnecessary xpcom_obsolete references (checked in)
Assuming it all builds, sr=me.
Attachment #129044 -
Flags: superreview?(bryner) → superreview+
Attachment #129044 -
Attachment description: remove unnecessary xpcom_obsolete references → remove unnecessary xpcom_obsolete references (checked in)
Comment 13•21 years ago
|
||
sorry for bug spam. bug 131289 was added by mistake.
No longer depends on: 131289
Updated•19 years ago
|
QA Contact: kandrot → nobody
Updated•18 years ago
|
Assignee: pete → nobody
Status: ASSIGNED → NEW
QA Contact: nobody → xpcom
Comment 14•17 years ago
|
||
Shouldn't nsIFileSpec (note the "I") be removed as well?
http://mxr.mozilla.org/seamonkey/source/xpcom/obsolete/nsIFileSpec.idl#39
It's still used in libpref, see bug 214796.
Summary: eliminate nsFileSpec → eliminate nsFileSpec and nsIFileSpec
Comment 15•15 years ago
|
||
AFAIK xpcom/obsolete is only used by mailnews and is in the process of being removed. We certainly don't build it as part of XULRunner/Firefox any more. I don't think this bug is worth tracking independently.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Comment 16•15 years ago
|
||
xpcom/obsolete has been removed by bug 514131 on mozilla-central (Gecko 1.9.3a1pre).
Blocks: 514131
You need to log in
before you can comment on or make changes to this bug.
Description
•