6181 - [PP]Need a way to control file types on Mac

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Simon Fraser [no longer active]]

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.

Comment 1

[don]

John, is this a bug or a feature?  When should we fix or implement it?

Comment 2

[mcmullen]

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.

Comment 3

[Simon Fraser [no longer active]]

I'm just looking for a programmatic way to do this.

Comment 4

[mcmullen]

Accepting bug

Comment 5

[Warren Harris]

Accepting for now, but I think someone else who knows this stuff is going to
have to own it long term (simon?).

Comment 6

[chris hofmann]

m8

Comment 7

[Warren Harris]

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?

Comment 8

[Simon Fraser [no longer active]]

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

[Warren Harris]

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.

Comment 10

[Simon Fraser [no longer active]]

That might work too. Do we have an enum of the 'special' files that we create?

Comment 11

[Doug Turner (:dougt)]

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.

Comment 12

[Warren Harris]

Doug: You should own this bug now.

Comment 13

[Doug Turner (:dougt)]

Have fix.  Sdagley reviewed it.  Waiting to checkin.

Comment 14

[Warren Harris]

What's the solution for this?

Comment 15

[Doug Turner (:dougt)]

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

[Warren Harris]

Shouldn't we be returning nsresult instead of OSErr?

Comment 17

[Doug Turner (:dougt)]

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?

Comment 18

[Simon Fraser [no longer active]]

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.

Comment 19

[Doug Turner (:dougt)]

good suggestion!  I will change the two methods to one.

Comment 20

[Warren Harris]

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.

Comment 21

[Doug Turner (:dougt)]

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.

Comment 22

[Doug Turner (:dougt)]

fixed checked in.

Comment 23

[Eli Goldberg]

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.)