You're welcome. Glad you liked it.
I've since sent my patch upstream to the rox-devel mailing list.
[rox-devel] Patch to provide support for application/x-zerosize
npierce wrote:3. The new code that supports application/x-zerosize in the xdgmime code base seems to have a bug. It only works if there is support for loading the mime.cache file into shared memory.
I've also reported that bug to freedesktop.org's Bugzilla.
Bug 55120 - application/x-zerosize isn't supported when not using cache.
npierce wrote:The /usr/share/mime/magic file that came with Racy 5.2.2 properly associates a file beginning with 49 44 33 ("ID3") with an audio/mpeg MIME type, but says nothing about a file beginning with FF FB. Instead it also associates a file beginning with 00 00 FF FB with an audio/mpeg MIME type. I suspect that those zeros are a mistake.
I would have reported this bug as well, but I found that it had already been fixed on 2011-Nov-04, so should be in shared-mime-info database 1-0 (released 2012-Jan-17).
Fix magic for MP3 files without ID3
(Latest release in Puppy no-arch repository is 0-70 (released 2009-Oct-06).)
miriam wrote:I'm trying to force myself to keep my nose to the grindstone (another painful metaphor) to produce a series of pictures of the major epochs in Earth's history and I'm notoriously easily distracted.
Assuming that the grindstone wasn't invented before the Pleistocene epoch, you can't keep your nose to it until you get there.
Anyway, good luck with your painting. It sounds like a fun project -- although finding models must be difficult unless you happen to have a tardis.
miriam wrote:I guess the secret to solving misidentified zero-sized mimetypes would be found if I dig into the ROX-Filer code.
Yes, you would probably only need to move the order of the tests in the relevant functions, so that the test for an empty file is called before the test for a matching glob. If and when you go there, have a look at xdg_mime_get_mime_type_for_file() and _xdg_mime_cache_get_mime_type_for_file() in xdgmime.c and xdgmimecache.c.
Before you go to the trouble, though, are you sure that you really want to change that behavior? Some folks might not classify them as "misidentified".
One person might argue that if someone created a file and named it test.pdf, they obviously intended it to have an application/pdf MIME type, otherwise they would have given it a different name. Another person might counter with, "Maybe, but look at the file: it's empty. Its not an application/pdf; it's not anything! It's just an empty file, so it must have MIME type application/x-zerosize."
Who is correct? Both are. There is no official definition of MIME types with an "x-" prefix.
RFC 4288: Media Type Specifications and Registration Procedures, § 3.4. Special x. Tree wrote:These types are unregistered, experimental, and for use only with the active agreement of the parties exchanging them.
(Source:
RFC 4288 Section 3.4)
"the active agreement of the parties exchanging"?!
Remember that the second 'M' in "MIME" is for "Mail". So originally this meant that, when sending e-mail attachments, you and your Aunt Agatha could decide what you wanted "x-zerosize" to mean, as long as you both agreed on it. You might even have a different definition of "x-zerosize" that you and your cousin Zeb agreed on when exchanging e-mail. (What?! Did I hear some people say that they
never discussed or debated with their correspondents about what definitions they would use for various experimental MIME types? Oh, for shame!)
The RFC goes on to say,
RFC 4288: Media Type Specifications and Registration Procedures § 3.4. Special x. Tree wrote:However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.
Ah, such optimism!
The glob and glob2 files created with the latest release of the shared-mime-info database (Release 1-0, 2012-Jan-17) contain 371 unregistered experimental types (up from 296 in Release 0-21, 2007-Apr-18 ). Maybe not all of those types are frequently used, but the fact that they made it into the database indicates that they are certainly used more than "rarely, if ever." (Oh, for comparison, how many registered types are in the database? 197 (up from 120 in Release 0-21).)
This problem of officially non-standard things becoming commonly used as if they were standard has been around for ages. One of the most notorious instances of this sort of thing is the legacy of ISO standard 646 allowing the code for LINE FEED to be used alternatively for NEW LINE. The language which allows this is similar to the "for use only with the active agreement of the parties exchanging them" in the MIME specification:
Third Draft Proposal on ISO 6 Bit and 7 Bit Codes (1964) wrote:The use of New Line requires agreement between the sender and the recipient of the data.
(Source:
H. McG. Ross, "The I.S.O. character code", The Computer Journal, vol 7, no. 3, October, 1964, pp. 197-202)
Over the decades there must have been millions of people-hours wasted by this confusion, and the need to translate text documents created in one O.S. for use on another O.S..
While it is too late to avoid the LINE FEED / NEW LINE confusion, there is hope that at least some of the x- MIME types may eventually get standardized. Since experience has shown that experimental types often end up being in common use, there is a plan in the works to modify RFC 4288 to allow people to create unregistered MIME types with a meaningful, currently unused name, without the need for an "x-" prefix (in fact, the "x-" prefix would be discouraged). Later, when it looked like the experimental type was a success, it could be registered with no need to change the name. And existing x- types would no longer be unregisterable, so their creators or maintainers could decide to register them "as is" with the "x-", or could choose to migrate them to a name without the "x-".
Media Type Specifications and Registration Procedures draft-ietf-appsawg-media-type-regs-14, § 3.4. Unregistered x. Tree wrote:Note that types with names beginning with "x-" are no longer considered to be members of this tree (see [
I-D.ietf-appsawg-xdash]). Also note that if a generally useful and widely deployed type incorrectly ends up with an "x-" name prefix, it MAY be registered using its current name in an alternate tree by following the procedure defined in Appendix A.
(Source:
Media Type Specifications and Registration Procedures draft-ietf-appsawg-media-type-regs-14, Section 3.4)
As far as I know, this is still just a draft document, and hasn't yet been approved to replace RFC 4288. So x- MIME types are currently still unregisterable. Time will tell if it gets approved.
Of course, a personal computer is personal. And no one needs the approval of any standards organisation to set it up to work best as fits her needs. So the possibility that some x- MIME types might one day get registered shouldn't dissuade you from modifying ROX-Filer to suit your needs.
A larger consideration would be the
Shared MIME-info Database "standard". Since that recommends that the filename glob has precedence over the file content, most software will probably follow the same convention. If you choose to follow a different drummer, be prepared to repeatedly patch new versions of ROX-Filer, or other file managers that you use, over the years.
Other than saving yourself some coding time, what other reasons might there be to leaving things as they are?
What point would there be in giving an empty file a MIME type other than application/x-zerosize?
Consider this, for instance:
Some folks, like me, are of the old school. We start an application, then click the
Open button to get the file we want to work on. Not surprisingly, to create a new file we also start the application and click the
New button.
Other folks are of the new school. They use their file manager to find the file that they want to work on, then click on its icon to run the appropriate application. They need not remember where the application lives. So they may find it easier to create a new file my creating and naming it with their file manager, then clicking on the new icon to run the application.
This is why I suggested in an earlier post that since an application/x-zerosize file was previously identified as a text/plain file, it might be a good idea to maintain the old behavior by setting the default run action for application/x-zerosize to be a text editor. But what if a user wants to create a word processing document or a spreadsheet? If all empty files are considered to be application/x-zerosize, then clicking the icon of a newly created file named test.abw or test.xls won't open the appropriate application.
Obviously, if you never use that method of creating files, you need not take that into consideration (unless you were to remaster your Puppy for others to use).
Anyway, thanks for taking the time to read through this rather long-winded post. I was looking into the various standards and fear that, as a result, I have burdened this post with more detail than was necessary.
Good luck with your painting and coding.