Allegedly, on or about 22 August 2016, Robert Moskowitz sent: > I prefer engrampa to xarchiver. In F22, after a couple times selecting > engrampa from the right click, Thunar just started using it as the > default. That has not happened in F24 (I download a couple lectures > each day as zips that require using the archive manager daily). > > I looked in preferences for thunar, and no where is there control for > the archive manager. Nor is there for xfce's default applications. > > Anyone with ideas, experiences? I realise this is a lengthy reply, but I'm trying to be thorough. If you want a possible quick answer, skip to the last paragraph. Is the behaviour in question: a. Following a link in a website/email, and directly opening the file? b. Opening a file from somewhere on your hard drive (desktop, file browser window, etc)? Because (a) is subject to two things. 1. The delivery system's metadata that says the following data's mimetype is "something-or-other." Whatever receives that data, follows the mimetype directives, rather than inspect the file, itself. Binary datatypes are supposed to say what the data is. For example, a PDF file could be described either as application/pdf and application/x-pdf (the x- prefix being an experimental mimetype proposal rather than a ratified official one), and your client really needs to be able to deal with both of them correctly (pass the data on to your PDF reader). It can also be ambiguously described as application/octet-stream, which simply some unknown kind of binary, which ought to simply saved, and you have to deal with the saved file in some other manner. This mimetype is a never-ending cause of problems (see further below). 2. The recipient (your software), accepting that data and handling according to the type of data that it is, as identified by the mimetype, even if the mimetype is wrong (if you get sent a PDF falsely described as a JPEG, the software should hand the file to your JPEG viewer, and let your JPEG view fail to show the data). It's then up to you to sort out the problem. Both halves of the equation have to work properly, transmission and reception, for data transmission *and* reception to work. There's just no avoiding that. The first half is out of your control, only the reception part is configurable by you. You can set up your favourite PDF viewer, JPEG viewer, etc., and that'll work fine for properly sent files. There is no it-will-always-work option for you to deal with improperly sent data. On the other hand, with the case for (b), of already stored data, it's *rather* similar, but not completely. It goes through the same processes, but instead of something *outside* telling you what kind of data is, the system identifies it, *itself*. It can do it by blind faith and ignorance, and simply assume that the filename suffix is an accurate description of the contents. Many systems work that way, and it usually works well, until you have some twit save a file with an inappropriate filename, or think that they can change the kind of data a file is simply be renaming it. Or, it can snoop into the file, and look for telltale signs about what type of data it is. Some filetypes have an explicit definition stored at the beginning of themselves, making that easy. Others have well-known characteristics that the computer can look for. And many systems work that way, too, sometimes as a backup after failing to work it out from the filename. Two drawbacks to the reading into the file method are that it can be computationally intensive, especially if doing this to a directory full of files, and if there's a software vulnerability that can be exploited, it's next to impossible to avoid it. The application/octet-stream mimetype problem: As mentioned, it's a generic "this is binary data" header, that does not identify what kind of data it is, leaving it up to you to determine that some other way. There are a great many number of servers which are not fully configured, so even commonly used data types (like PDF, ZIP, MPEGs) are not known to it, so it just gives them a generic binary header that gives little information about the data, other than it doesn't think it's simply text. The same goes for many other far less common types of data (e.g. the plethora of different types of file archiving and compression formats). Some people try and work around that by setting their software to always open this unknown binary as a PDF file, finding that it usually works okay for them. But it will fail the next time they get something else (that's not a PDF) sent with the unknown binary description. A better solution is to use another program as a handler for unknown data, let it snoop into the file, and palm it off to what it thinks is the appropriate program. There is still one problem with this approach, though, and that it *may* take away an easy option of saving things you want to download from a website, as that is the usual intention of the deliberate useage of application/octet-stream mimetypes (save the file, don't open it directly). If you change that behaviour, instead of downloading and saving a file you click on, it may stream to cache, and open in the application, and you may not always be able to save the file that application is showing (it depends on /that/ application). On Linux, there's at least two of these handling programs that I know about: gnome-open and xdg-open, with the latter intending to be a more generic system (for anything on X, rather than being gnome-centric). If you have one of these kind of programs installed, it may be in your interests to set *it* as the application to handle these surprise unknown binary files when your web browser (or mail client) asks you what to do with the file you've just clicked on. -- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 Boilerplate: All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I only get to see the messages posted to the mailing list. Just because nobody complains, it doesn't mean that all parachutes are perfect. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
