Hi, Amin. All my machines receive automatic security upgrades and I was surprised by this same issue: Havoc in proper functioning of Thunderbird's Enigmail plugin after Thunderbird upgrade to version 1:52.2.1-4~deb8u1.

I found that a newer version of Enigmail restored my ability to send encrypted email. However, if I want to both encrypt and sign, sending fails. Error messages appear in two successive windows:

GnuPG reported an error in the communication with gpg-agent (a component of GnuPG)

then

Sending of the message failed.

The "How to fix" tidbit from the Enigmail website (adding "use-standard-socket" to $HOME/.gnupg/gpg-agent.conf and rebooting) made no difference--signing a message still prevents it from being sent.

Enigmail can be obtained as a .deb package and installed by the package manager, or obtained as a .xpi package and installed from within Thunderbird (Thunderbird > Tools > Add-ons > click on down-arrow next to the little gear > "Install Add-on From File").

My workaround for the time being is to stick with the pre-upgrade versions of Thunderbird (45.8.0-3~deb8u1) and Enigmail (1.8.2 xpi package).

To prevent Thunderbird & Enigmail from being upgraded, I created /etc/apt/preferences.d/thunderbird-keep-v45 with these contents...

Package: thunderbird
Pin: version 1:45.8.0-3~deb8u1
Pin-Priority: 1001

...and in Thunderbird > Tools > Add-ons > click the down-arrow next to the little gear > make sure there's no checkmark by "Update Add-ons Automatically".

I renamed some video files and now the renamed ones have thumbnails. Bizarre.

Is there something I can do so that thumbnails show up for all videos, without me having to rename them all?

@greenjeans: Yes, the partition table was msdos from the start and I never changed that.

@golinux: I'm pretty sure manufacturers do that, but I doubt it was the cause because caja would automatically open the drives when they were new.

Here are the only things I can say for sure about this strange issue, based on much experimentation:
1. All my usb drives could be automatically opened by caja when they were new
2. Some usb drives consistently stopped being automatically opened by caja, regardless of distro (MATE on devuan, debian, or arch)
3. I thought the breakage was GParted's fault, but I was not able to prove that through recent experiments
4. I was not able to fix the problem using GParted (recreating the partition table and/or recreating partitions had no effect)
5. wipefs or zeroing the whole drive with dd fixes the problem. I ran out of "broken" drives to try zeroing just the beginning sectors.

Since I'm unable to reproduce the breakage, it's difficult to pinpoint exactly where the issue was. My best guess is that the culprit is some subtle corruption in early sectors of the drive that are inaccessible to parted/gparted's operations.

Why not just use the portable TorBrowser for GNU/Linux available here?

I tested it on Devuan Jessie and it works fine. It should run on Devuan ASCII just as well.

lazlo: Yes, running the two wipefs commands and then going into GParted to create the partition table and fat32 partition also works (converts a non-auto-opening thumbdrive to an auto-opening one). The wipefs commands are very fast, much better than waiting 30+ minutes for the original dd command.

Since I've bumped into this issue many times, here is a script that puts it all together: wipefs steps, new msdos partition table, creation of single partition as big as the device, formatting the partition to fat32, adding a label to the partition:

sudo umount /dev/sdb1   
sudo wipefs -a -f /dev/sdb1
sudo wipefs -a -f /dev/sdb
sudo parted /dev/sdb mklabel msdos &>/dev/null
sudo parted /dev/sdb mkpart primary 0% 100% &>/dev/null
while [ ! -e /dev/sdb1 ]; do sleep 1; done # because parted mkpart exits before it's done creating sdb1!
sleep 1
sudo mkfs.msdos -F 32 /dev/sdb1
sudo dosfslabel /dev/sdb1 "my_label"

EDIT: I'd try the targeted dd command as well, but at this point all of my "broken" thumbdrives have been fixed

WARNING: Before using the script above, make sure a) /dev/sdb is actually your thumbdrive (one way to check is with "sudo blkid"), and b) the thumbdrive contains no valuable data. If you have any doubt, don't run the script--it assumes these two things are true.

Haha. I know the feeling.

I will try dd and will post back in a few minutes.

In the meantime, the only demonstrable difference I can find between the sticks that auto-open and the ones that don't is the product id:

Here's one that doesn't auto-open:

bruno@thinkpad:~$ lsusb
---snip---
Bus 007 Device 006: ID 13fe:5500 Kingston Technology Company Inc. 
---snip---

And here's one that does:

bruno@thinkpad:~$ lsusb
---snip---
Bus 007 Device 007: ID 13fe:4100 Kingston Technology Company Inc. 
---snip---

Notice the same vendor id (13fe) but different product id (5500 vs. 4100). Could this have anything to do with it?

greenjeans: That was a really good idea. Yes, I was trying the stick fresh without any content. Alas, adding files makes no difference (i.e., the stick automounts and icon shows up on desktop, but caja does not automatically open it).

Just to check my sanity, I found two other thumbdrives and can confirm that caja automatically opens them. Therefore, caja continues to (sometimes) respect my setting to automatically "Browse media when inserted".

Are you ready for something very strange? I took one of these new sticks and formatted the existing partition to fat32 using GParted. Then I took the other stick, deleted its existing partition, created a new partition, and formatted to fat32 (all using GParted). Surprise: Caja continues to automatically open these two sticks, no problem.

So at this point I can't seem to reproduce my problem. What I can say for sure is that caja consistently opens some sticks and consistently doesn't open others, despite the fact that all of these sticks have been formatted in GParted in the exact same way. All the sticks are of same brand (Patriot Memory), but different models.

I have both varieties of sticks here (auto-open and no-auto-open) in case someone can think of a helpful comparison to make between them.

No joy there, either. I opened caja with root and it also has a check by "Browse media when inserted".

By the way:
When I right-click on the Desktop icon of a USB drive that DOES automatically open and go to Properties, it says "Type: folder (inode/directory)".
When I do the same thing to a USB drive that DOESN'T automatically open, it also says "Type: folder (inode/directory)".

Are these the drives' x-content settings? If so, the x-content is identical and therefore not the culprit.

I consider these two to be the most definitive:

http://mywiki.wooledge.org/BashGuide (the pitfalls section is especially good: http://mywiki.wooledge.org/BashPitfalls)

http://tldp.org/LDP/abs/html/

The best way to get started with shell programming is to write scripts that solve your simple real-world problems (any time you find yourself thinking "wouldn't it be nice if my computer could do _____ automatically?" counts as a real-world problem). You then tackle increasingly more complex problems. As you do this, consult references on an as-needed basis. If you get stuck, ask.

I think reading the two references above start to finish would be most helpful after you've written several scripts and are comfortable with the basics.

If you want to give the Firefox52 AppImage a shot, just follow the steps in my post #9 above, but use this instead of the wget line in that post:

wget https://bintray.com/probono/AppImages/download_file?file_path=Firefox-52.0.1.glibc2.3.4-x86_64.AppImage -O Firefox52.AppImage

I'd be interested in knowing if it's the sse2 issue that made Firefox53 a no-go for you.