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.

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

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.

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

Accepting bug

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

m8

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?

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.

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.

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

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.

Doug: You should own this bug now.

Have fix. Sdagley reviewed it. Waiting to checkin.

What's the solution for this?

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; > }

Shouldn't we be returning nsresult instead of OSErr?

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?

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.

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

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.

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.

fixed checked in.

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