@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.

My best guess in this case is that there is either:

A.)  An incompatible partition table as Greenjeans mentioned

or

B.)  Some sort of minor corruption of data in the partition table.  While it may not be enough to cause a loss of data in robust environment like Devuan, it might keep the system from auto mounting the drive or stop Caja from auto running the file browser. 

It is also possible that there was a hidden autorun.inf somewhere on the drives that the manufacturer placed there to run their proprietary software, as Golinux suggested.  I don't know if such a file would have much effect in linux even if you have wine installed.  It would have to point to an executable program of some type and if the drive had been previously formatted it would be missing. 

I do not think that left over information in the boot sector is the cause because wipefs won't erase data according to this excerpt from it's man page:

wipefs does not erase the filesystem itself nor any other data from the
       device.  When used  without  any  options,  wipefs  lists  all  visible
       filesystems and the offsets of their basic signatures.

Which brings us to gparted...should it be removing the old partition data by either doing the same thing wipefs does or by calling wipefs?  Or should it just be overwriting the partition table and file system as it seems to be doing?  If it is the former, this points to a bug.  If it is the latter perhaps it needs a call to wipesfs in order to prevent this issue in the future.

lazlo

Alas, just creating a new partition table was not enough.

The only way to get caja to start automatically opening previously-ignored sticks was dd or wipefs, followed by creation of new partition table and new partition through whatever method.

That's so bizarre. What kind of partition table was on the bad sticks to start with, ms-dos?

The only way to get caja to start automatically opening previously-ignored sticks was dd or wipefs, followed by creation of new partition table and new partition through whatever method.

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.

lazlo: You nailed it!

0. I plugged in a thumbdrive that caja wasn't automatically opening, then...
1.

sudo umount /dev/sdb1

2.

sudo dd if=/dev/zero of=/dev/sdb

3. I went into GParted and when I chose sdb it complained about there being no partition table--presumably because it was overwritten with zeros by the dd command--so I went ahead and created an msdos partition table.
4. Still in GParted, I created an sdb1 partition with fat32 filesystem.

Then I removed the thumbdrive and plugged it back in, and... CAJA AUTOMATICALLY OPENED IT!

I tried cheating with a different thumbdrive, hoping that skipping the time-consuming dd step and going straight to creating a new partition table would be enough, but no luck with that.

While I will continue to wonder where exactly was the problem, thanks to you we have a fix. Thanks a lot! This has bothered me for a long time, since long before Devuan.

OK, since that actually worked, (yes, I am a bit surprised) then in order to narrow down what the issue is the next thing I would try is:

wipefs -a -f /dev/sdb1
wipefs -a -f /dev/sdb

and see if it has the same results.  If so you may have found a bug in gparted.

Thanks for letting me know that dd worked!

EDIT:  After giving it more thought I realized that if wipefs doesn't do the trick you could probably just run dd like this:

dd if=/dev/zero of=/dev/sdb count=512 bs=4K

That would just wipe the first two megabytes of space on the drive which would contain the boot sector and the partition table.  If that doesn't work you can speed up the drive over wite with:

dd if=/dev/zero of=/dev/sdb bs=8M

lazlo

0. I plugged in a thumbdrive that caja wasn't automatically opening, then...
1.

sudo umount /dev/sdb1

2.

sudo dd if=/dev/zero of=/dev/sdb

3. I went into GParted and when I chose sdb it complained about there being no partition table--presumably because it was overwritten with zeros by the dd command--so I went ahead and created an msdos partition table.
4. Still in GParted, I created an sdb1 partition with fat32 filesystem.

Then I removed the thumbdrive and plugged it back in, and... CAJA AUTOMATICALLY OPENED IT!

I tried cheating with a different thumbdrive, hoping that skipping the time-consuming dd step and going straight to creating a new partition table would be enough, but no luck with that.

While I will continue to wonder where exactly was the problem, thanks to you we have a fix. Thanks a lot! This has bothered me for a long time, since long before Devuan.

I hate a puzzle I can't solve. I'll be thinking about this forever if I don't find a good solid reason for it.

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?

dd if=/dev/zero of=/dev/sdb

and then run gparted?  I am thinking that *maybe* something is not being over written or not writing correctly to the usb drives that have the issue.  Honestly though, I don't expect it to do any good.

EDIT:  Could it be bad sectors close to the beginning of the drive preventing a vital bit of information from updating the status of the device somewhere below the caja mount process?  Or maybe it's a slight difference in the low level hardware that communicates between the block layer and the flash chip of the usb drive itself?  I know it's grasping at straws, but I hate a puzzle I can't solve.  I'll be thinking about this forever if I don't find a good solid reason for it.

lazlo

I'll keep at it when I have time, and will post any new insights here.

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.

If you run gparted and format the usb stick to something, but don't add any content to the disk before trying it, it will automount the stick but not open Caja. If you put any piece of content whatsoever on the stick, then it will auto-open as well as auto-mount.

Gnuser are you trying the stick fresh from re-formatting but with no content?