Closed
Bug 6181
Opened 25 years ago
Closed 25 years ago
[PP]Need a way to control file types on Mac
Categories
(Core :: XPCOM, defect, P2)
Tracking
()
RESOLVED
FIXED
M10
People
(Reporter: sfraser_bugs, Assigned: dougt)
References
Details
It would be great if on Mac we could control file types & creators of files
created via nsFileSpec. This can't always be based on file extension, because
files saved via a PutFile dialog can't be relied upon to have file extensions
in their names.
Changed component to XP File handling.
It might be a feature. Simon, are you suggesting UI for this, or simply a
programmatic way to set it? If you want UI, it would certainly be a feature.
Otherwise, it might be a bug, if you provide an example of use that shows that we
are doing the wrong thing.
Actually, nsFileSpec never creates files, it is nsFileStream that does so. So
perhaps adding a method do the stream classes might fill the bill. Currently,
nsFileStream always uses TEXT,MOSS (I know, should be MOZZ) for optimized and
TEXT, CWIE for debug.
Reporter | ||
Comment 3•25 years ago
|
||
I'm just looking for a programmatic way to do this.
Summary: Need a way to control file types on Mac → [PP]Need a way to control file types on Mac
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 5•25 years ago
|
||
Accepting for now, but I think someone else who knows this stuff is going to
have to own it long term (simon?).
Updated•25 years ago
|
Target Milestone: M7 → M8
Comment 6•25 years ago
|
||
m8
Comment 7•25 years ago
|
||
Can we move this to M9? That will allow us to do it in the necko context
instead of netlib. Simon, can you help us with this?
Reporter | ||
Comment 8•25 years ago
|
||
I guess I can help out, not by M9 though. I think we just need some XP_MAC
methods on nsFileSpec to supply type and creator information for new files.
Comment 9•25 years ago
|
||
Cc'ing dougt -- nsFileSpec's new owner.
2 cents: Does this really need to be a new interface method for the Mac? Maybe
it can just be a lookup table in the implementation.
Reporter | ||
Comment 10•25 years ago
|
||
That might work too. Do we have an enum of the 'special' files that we create?
Assignee | ||
Comment 11•25 years ago
|
||
The non-xp stuff in nsFileSpec, or should I say the mac stuff in nsFileSpec,
should be moved into a mac specific interface.
For the short term, these calls can be placed in the #ifdef XP_MAC section. A
goal of the redesign of nsFileSpec and nsFileChannel will be to get rid of
these platform specific entry points and place them in platform
specific interface similar to what is being done with the native xp event loop.
Updated•25 years ago
|
Assignee: warren → dougt
Status: ASSIGNED → NEW
Target Milestone: M9 → M10
Comment 12•25 years ago
|
||
Doug: You should own this bug now.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•25 years ago
|
||
Have fix. Sdagley reviewed it. Waiting to checkin.
Comment 14•25 years ago
|
||
What's the solution for this?
Assignee | ||
Comment 15•25 years ago
|
||
I did want I proposed above. I have added two new APIs to nsFileSpec (not the
nsIFileSpec). Here is the diff:
Index: nsFileSpec.h
===================================================================
RCS file: /cvsroot/mozilla/xpcom/io/nsFileSpec.h,v
retrieving revision 1.45
diff -r1.45 nsFileSpec.h
363c363,366
<
---
> OSErr SetFileType(OSType type);
> OSErr SetCreatorType(OSType type);
Index: nsFileSpecMac.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpcom/io/nsFileSpecMac.cpp,v
retrieving revision 1.32
diff -r1.32 nsFileSpecMac.cpp
1075a1076,1103
>
//-----------------------------------------------------------------------------
-----------
> OSErr nsFileSpec::SetFileType(OSType type)
>
//-----------------------------------------------------------------------------
-----------
> {
> FInfo info;
> OSErr err = ::FSpGetFInfo (mSpec, &info);
> if (err != noErr)
> return err;
> info.fdType = type;
> err = ::FSpSetFInfo (mSpec, &info);
> return err;
> }
>
>
//-----------------------------------------------------------------------------
-----------
> OSErr nsFileSpec::SetCreatorType(OSType type)
>
//-----------------------------------------------------------------------------
-----------
> {
> FInfo info;
> OSErr err = ::FSpGetFInfo (mSpec, &info);
> if (err != noErr)
> return err;
> info.fdCreator = creator;
> err = ::FSpSetFInfo (mSpec, &info);
> return err;
> }
Comment 16•25 years ago
|
||
Shouldn't we be returning nsresult instead of OSErr?
Assignee | ||
Comment 17•25 years ago
|
||
Since this is a mac specific routine and it is a C++ non-xpcom class, it really
does not matter. Other functions in the mac def'ed part of nsFileSpec are
doing the same thing.
Once this is rolled into nsIFile (the new and improved nsFileSpec), all results
will be nsresults.
Either way, I do not care. Simon, do you have any preference?
Reporter | ||
Comment 18•25 years ago
|
||
You need to propagate failure codes back, so you should certainly do an OSErr ->
nsresult translation somwhere. I don't really care where.
Also, you might just as well have a single method for setting type and creator,
since it's rare that you'll not be setting these at the same time.
Assignee | ||
Comment 19•25 years ago
|
||
good suggestion! I will change the two methods to one.
Comment 20•25 years ago
|
||
Also, don't you want getters too?
Re: OSErr -- maybe all the methods that return these should be changed so that
they perform the OSErr->nsresult mapping internally. Either that, or the
mapping function needs to be exposed so that this is handled consistently.
Assignee | ||
Comment 21•25 years ago
|
||
Getters would be a good enhancement.
I am not going to map these OSErr's into nsresult this go around. Currently,
there are two functions already returning OSErr in nsFileSpec and eight not
returning nsresult. In the new world (nsIFile), this will change.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 22•25 years ago
|
||
fixed checked in.
Comment 23•25 years ago
|
||
Bulk moving to XPCOM, in preparation for removal of XP File Handling component.
(XPFH has received two bugs in ~5 months, and is no longer in active use.)
Component: XP File Handling → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•