217723 - BeOS port should get file's mime types from the operating system

Status: RESOLVED WONTFIX

(Core Graveyard :: File Handling, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: something like this

I still need to test this, though

Comment 2

[Sergei Dolgov]

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

Comment 3

[Sergei Dolgov]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Jungshik Shin]

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)

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: working patch... sorta

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

Comment 8

[Sergei Dolgov]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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?

Comment 10

[Sergei Dolgov]

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

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 12

[Sergei Dolgov]

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

Comment 13

[Sergei Dolgov]

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

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: mozilla.in patch

ok, with this additional patch, mozilla starts up

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 16

[Sergei Dolgov]

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.

Comment 17

[Paul]

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

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 19

[Simon]

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.

Comment 20

[Sergei Dolgov]

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

Comment 21

[Niels Reedijk]

Moving forward to Firefox 3.0.

Comment 22

[Sergei Dolgov]

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

Comment 23

[Sergei Dolgov]

Attachment: patch

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

Comment 24

[Sergei Dolgov]

Attachment: patch

added defines for BEntry and relative headers

Comment 25

[Doug Shelton]

second patch applies cleanly, builds and works as documented.

Comment 26

[Sergei Dolgov]

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

request for first review

Comment 27

[Sergei Dolgov]

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

second review request

Comment 28

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

BeOS is dead.