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

RESOLVED WONTFIX

Status

Core Graveyard
File Handling
RESOLVED WONTFIX
14 years ago
a year ago

People

(Reporter: Biesinger, Assigned: Sergei Dolgov)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 4 obsolete attachments)

nsExternalHelperAppService::GetTypeFromFile can use OS APIs on BeOS to get the
mime type
Created attachment 130592 [details] [diff] [review]
something like this

I still need to test this, though
(Assignee)

Comment 2

14 years ago
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 &) 
(Assignee)

Comment 3

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
> 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.
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
Attachment #130592 - Attachment is obsolete: true
(Assignee)

Comment 8

14 years ago
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

14 years ago
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?
(Assignee)

Comment 10

14 years ago
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.
(Assignee)

Comment 12

14 years ago
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
(Assignee)

Comment 13

14 years ago
>>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).
Created attachment 130690 [details] [diff] [review]
mozilla.in patch

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

Comment 16

14 years ago
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

14 years ago
> ; 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
Assignee: cbiesinger → file-handling
QA Contact: chrispetersen → ian

Updated

13 years ago
Blocks: 266252

Comment 19

13 years ago
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.

Updated

12 years ago
No longer blocks: 266252

Updated

12 years ago
Blocks: 311032
(Assignee)

Comment 20

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

Comment 21

11 years ago
Moving forward to Firefox 3.0.
Blocks: 356310
No longer blocks: 311032
(Assignee)

Updated

10 years ago
Blocks: 405023
(Assignee)

Comment 22

10 years ago
> 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;
    }
  }
(Assignee)

Comment 23

10 years ago
Created attachment 294859 [details] [diff] [review]
patch

matches code in attachment 130666 [details] [diff] [review], but with two checks added - see comment #22
Assignee: file-handling → sergei_d
Attachment #130666 - Attachment is obsolete: true
Attachment #130690 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #294859 - Flags: review?
(Assignee)

Comment 24

10 years ago
Created attachment 295019 [details] [diff] [review]
patch

added defines for BEntry and relative headers
Attachment #294859 - Attachment is obsolete: true
Attachment #294859 - Flags: review?

Comment 25

10 years ago
second patch applies cleanly, builds and works as documented.
(Assignee)

Comment 26

10 years ago
Comment on attachment 295019 [details] [diff] [review]
patch

request for first review
Attachment #295019 - Flags: review?(doug)

Updated

10 years ago
Attachment #295019 - Flags: review?(doug) → review+
(Assignee)

Comment 27

10 years ago
Comment on attachment 295019 [details] [diff] [review]
patch

second review request
Attachment #295019 - Flags: review?(cbiesinger)
QA Contact: ian → file-handling
BeOS is dead.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Attachment #295019 - Flags: review?(cbiesinger)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.