nsExternalHelperAppService::GetTypeFromFile can use OS APIs on BeOS to get the mime type

I still need to test this, though

Biesi, i'm correcting here BeOS-specific problems with this code at moment, but there is more generic mozilla-complaint by compiler: mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp:2317: no matching function for call to `ToNewCString (char[241])' mozilla/dist/include/string/nsReadableUtils.h:62: candidates are: ToNewCString(const nsAString &) /mozilla/dist/include/string/nsReadableUtils.h:74: ToNewCString(const nsACString &)

Problem is that with my source tree (1.4 release) i don't see program entering this method (i've put debug printfs there): #ifdef XP_BEOS nsCAutoString path; aFile->GetNativePath(path); if (!path.IsEmpty()) { printf("BeOS Native mime path%s\n", path.get()); BNode node(path.get()); // if (update_mime_info( path.get(), 0, 1, 0) == B_OK ) //must be done before mime-type reading, forces type setting/recofnition for fresh files - fyysik if (node.InitCheck() == B_OK) { char mimeType[B_MIME_TYPE_LENGTH + 1]; if(node.ReadAttr("BEOS:TYPE",0,0,mimeType,B_MIME_TYPE_LENGTH + 1) > 0) { printf("BeOS Native mime type%s\n", mimeType); aContentType[0] = mimeType; fflush(stdout); return NS_OK; // Otherwise, go down the normal path } } else printf("BeOS Native mime path%s is Empty\n", path.get()); } #endif

The way to enter that code is to load a file:// url with an "odd" extension (eg a .pdf) Question. Do we have to put all these platform hacks in this method? Or could we make the method virtual and override it on a per-platform basis in nsOSHelperAppService?

On Unix, 'relying on OS' could mean going back to old 'Mosaic' days ( mime-types file) As a supplement to our internal mapping, it wouldn't be bad. Another possibility is to do what 'file' command does (if it's not already done, but I don't think there's any standard API for that on POSIX)

> mime-types file You should read this code, really, since that's exactly what it does. ;) And no, there is no reasonable way to invoke 'file' short of actually running it in a subprocess or something.

thanks to fyysik, I have a basically working patch. now, the problem is this: BeOS doesn't recognize RDF or XML mime types (by default) Mozilla fails badly if a rdf file (chrome.rdf) gets called text/plain, on startup the .xml is also important so, this sucks

Heh, troubles in OS with most elegant way of filetype handling. Such irony... Well, maybe something can be done in other places in Mozilla code, but some workarounds are possible 1)in install/launch script checking for existance of neccessary for Mozilla mime-types and adding it to system, with suitable extensions 2)In build/packaging process adding mime-types to files in proper BeOS way - as file attributs 3)Using forced sniffing for certain set of extensions, something alike: #define sniffer " '.RDF' | '.Rdf' | '.rdf'" BMimeType mime_type("application/rdf-xml);// ???? mime_type.SetSnifferRule(sniffer); BPath path(ent); BMimeType::GuessMimeType(path.Path(), &mime_type);

So... imo we could just special-case the "trouble" extensions in the BeOS code as "not to be looked up". Or add the metadata during the build process as suggested. How hard would the latter be?

there are shell comands for such purposes like "addattr" "copyattr" "settype" for changing file metadata and "setmime" for global mime database

> Or add the metadata during the build process as suggested. Hm... Mozilla builds are distributed as zip files... can they contain mime-type info? And note that this wouldn't be enough. Mozilla creates files like $PROFILE/chrome/chrome.rdf. Without a mime type. >1)in install/launch script checking for existance of neccessary for Mozilla >mime-types and adding it to system, with suitable extensions This would be the solution that I would prefer.

BeOS /bin/zip preserves attributes. This is why it is strongly recommended to export/store BFS files on non-BFS volumes in zipped form. Though, unsure if gzip is metadata aware

>>1)in install/launch script checking for existance of neccessary for Mozilla >>mime-types and adding it to system, with suitable extensions >This would be the solution that I would prefer. /bin/setmime is tool for this task. Though, our goal is get rid of launch script. It means that we should change way of bezilla installation (just unzipping at moment) or put mime checking and setting somewhere in bootstrap. You can try setmime just now (type it without parameters to see syntax). It allows to set sniffing by extension rules, IIRC. So i'm wondering if your build starts properly after such operation. Though, to force scanning and updating of mime-types sometimes launch of /bin/mimeset is required (quite long process, usually OS does it permanently by Registar daemon in background).

ok, with this additional patch, mozilla starts up

> BeOS /bin/zip preserves attributes. Oh, I saw this comment only now In this case, it might also be a good idea to change the build process to set these mime types; and to change mozilla to set mime types on the files it creates (instead of using the mozilla.in patch here)...

Biesi, there may be penalty with attribute packing. Distro with big number of small files grows noticeably in size. I'm afraid that each file gets overhead in one cluster size. And even if we add attributes in buidl process, i think it is good idea (TM) to set system-wide mime-info for those files, as you did it using setmime. After some time all rdf-s and xml-s will get metadata assigned automatically, with Registar daemon, as i said, if we have system-wide rules for type recognition. And if we don't wish wait or don't rely on registar - update_mime_info() used in your code, does this job for every file Mozilla touches with the method.

> ; and to change mozilla to set mime types on the files it creates This was an actual bug, Bug#69891. I had closed it, thinking that the Helper class resolved the issue, which, it "kindof" does, but, it does not acutally set the mime-type, unless it opens/launches the file, at which point, the registrar (i think) sets it.

doesn't look like I'll get to this anytime soon (unfortunately), -> default owner

Just seen this actually. You can force the registrar to figure out the mime type by doing update_mime_info - see bug 269280 (my moz-icon implementation), which does just this if the file is local and has not yet been identified by BeOS.

Biesi, we can set important file types (like rdf and xml) via application resource file.

Moving forward to Firefox 3.0.

> BeOS doesn't recognize RDF or XML mime types (by default) > Mozilla fails badly if a rdf file (chrome.rdf) gets called text/plain, on > startup > the .xml is also important > > so, this sucks Patch looks working ok, but I had put beos section after getting extension for leaf, and before call for GetTypeFromExtension(). For safety, regarding comment #7, added in BeOS section before native code, if extension exists, following, borrowed from GetTypeFromExtension: #if defined(XP_BEOS) if (!fileExt.IsEmpty()) { for (size_t i = 0; i < NS_ARRAY_LENGTH(defaultMimeEntries); i++) { if (fileExt.LowerCaseEqualsASCII(defaultMimeEntries[i].mFileExtension)) { aContentType = defaultMimeEntries[i].mMimeType; return rv; } } //Check RDF DS PRBool found = PR_FALSE; found = GetTypeFromDS(fileExt, aContentType); if (found) { return NS_OK; } }

matches code in attachment 130666 [details] [diff] [review], but with two checks added - see comment #22

added defines for BEntry and relative headers

second patch applies cleanly, builds and works as documented.

Comment on attachment 295019 [details] [diff] [review] patch request for first review

Comment on attachment 295019 [details] [diff] [review] patch second review request

BeOS is dead.