Last Comment Bug 217723 - BeOS port should get file's mime types from the operating system
: BeOS port should get file's mime types from the operating system
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: File Handling (show other bugs)
: Trunk
: x86 BeOS
: -- normal (vote)
: ---
Assigned To: Sergei Dolgov
:
Mentors:
http://bang.dhs.org/be/bebook/The%20S...
Depends on:
Blocks: 356310 405023
  Show dependency treegraph
 
Reported: 2003-08-29 06:42 PDT by Christian :Biesinger (don't email me, ping me on IRC)
Modified: 2016-06-22 12:16 PDT (History)
9 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
something like this (2.33 KB, patch)
2003-08-29 06:57 PDT, Christian :Biesinger (don't email me, ping me on IRC)
no flags Details | Diff | Splinter Review
working patch... sorta (3.17 KB, patch)
2003-08-30 17:50 PDT, Christian :Biesinger (don't email me, ping me on IRC)
no flags Details | Diff | Splinter Review
mozilla.in patch (621 bytes, patch)
2003-08-31 15:43 PDT, Christian :Biesinger (don't email me, ping me on IRC)
no flags Details | Diff | Splinter Review
patch (2.27 KB, patch)
2007-12-29 12:56 PST, Sergei Dolgov
no flags Details | Diff | Splinter Review
patch (2.62 KB, patch)
2008-01-01 09:45 PST, Sergei Dolgov
doug: review+
Details | Diff | Splinter Review

Description Christian :Biesinger (don't email me, ping me on IRC) 2003-08-29 06:42:14 PDT
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) 2003-08-29 06:57:52 PDT
Created attachment 130592 [details] [diff] [review]
something like this

I still need to test this, though
Comment 2 Sergei Dolgov 2003-08-29 10:18:12 PDT
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 2003-08-29 12:00:14 PDT
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 [:bz] 2003-08-29 12:06:16 PDT
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 2003-08-29 22:29:20 PDT
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 [:bz] 2003-08-30 08:18:00 PDT
> 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) 2003-08-30 17:50:04 PDT
Created attachment 130666 [details] [diff] [review]
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 2003-08-30 20:32:51 PDT
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 [:bz] 2003-08-30 21:36:46 PDT
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 2003-08-31 05:01:36 PDT
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) 2003-08-31 05:15:15 PDT
> 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 2003-08-31 06:19:03 PDT
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 2003-08-31 06:37:53 PDT
>>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) 2003-08-31 15:43:05 PDT
Created attachment 130690 [details] [diff] [review]
mozilla.in patch

ok, with this additional patch, mozilla starts up
Comment 15 Christian :Biesinger (don't email me, ping me on IRC) 2003-09-01 04:37:00 PDT
> 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 2003-09-01 05:03:59 PDT
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 2003-09-01 15:52:21 PDT
> ; 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) 2004-10-01 14:28:54 PDT
doesn't look like I'll get to this anytime soon (unfortunately), -> default owner
Comment 19 Simon 2005-02-25 00:29:59 PST
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 2006-02-19 09:44:12 PST
Biesi, we can set important file types (like rdf and xml) via application resource file.
Comment 21 Niels Reedijk 2006-10-11 12:16:09 PDT
Moving forward to Firefox 3.0.
Comment 22 Sergei Dolgov 2007-11-22 16:17:15 PST
> 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 2007-12-29 12:56:18 PST
Created attachment 294859 [details] [diff] [review]
patch

matches code in attachment 130666 [details] [diff] [review], but with two checks added - see comment #22
Comment 24 Sergei Dolgov 2008-01-01 09:45:11 PST
Created attachment 295019 [details] [diff] [review]
patch

added defines for BEntry and relative headers
Comment 25 Doug Shelton 2008-01-01 12:00:46 PST
second patch applies cleanly, builds and works as documented.
Comment 26 Sergei Dolgov 2008-01-03 08:54:23 PST
Comment on attachment 295019 [details] [diff] [review]
patch

request for first review
Comment 27 Sergei Dolgov 2008-01-03 09:28:10 PST
Comment on attachment 295019 [details] [diff] [review]
patch

second review request
Comment 28 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-10-11 07:53:24 PDT
BeOS is dead.

Note You need to log in before you can comment on or make changes to this bug.