You are not logged in.
I'm on Devuan Jessie with MATE. When I use a brand-new USB drive, plugging in the drive causes it to first appear on the Desktop then, after a very brief interval, the file manager (caja) automatically opens a window at the root of the drive. Very nice.
For some strange reason, if I then format the USB drive in GParted (my tool of preference for such tasks), plugging in the drive still causes an icon for it to show up on the Desktop, but now I have to actually click on the Desktop icon in order to browse the files--caja no longer automatically opens a window at the root of the drive.
A screenshot of how I'm formatting the drive is below. What do I need to do so that after formatting a USB drive, caja will continue to automatically open it for browsing when the drive is plugged in?
More generally: Why does caja automatically open some thumbdrives but not others of the same brand?
Last edited by GNUser (2017-06-30 19:32:19)
Offline
There are settings in dconf related to automount, and automount-open that are usually both active in the default install, that's why it automounts it and continues to automount after formatting.
Automount-open however, only works on media for which no known x-content is detected, if the media is recognized it will use the user-specified action instead.
Open caja, click Edit>>Preferences>>Media>> and be sure that the bottom box "Browse media when inserted" is checked. If that doesn't work you may need to add to the mimeapps.list
Last edited by greenjeans (2017-06-29 19:16:52)
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Thanks, greenjeans. Caja's "Browse media when inserted" is already checked.
Maybe formatting in GParted causes the thumbdrive's x-content to change? How do I check its current x-content and, if applicable, change it to something that will continue to trigger Automount-open?
Last edited by GNUser (2017-06-29 19:32:58)
Offline
Thanks, greenjeans. Caja's "Browse media when inserted" is already checked.
Maybe formatting in GParted causes the thumbdrive's x-content to change? How do I check its current x-content and, if applicable, change it to something that will continue to trigger Automount-open?
Can't be gparted, I use it all the time and have never had the issue. Your x-content in this case is simply the fat32 filesystem you put on the usb, if it mounts it you're fine, just need to auto-open.
Just for giggles, open caja as root, and make sure that box is checked for root user as well.
Mate is funny like that, i've had some glitches in the past where the system didn't want to honor the user's preferences because root preferences were different.
I'm using Mate right now and can confirm that unchecking that box stops auto-open on my machine, and re-checking it makes it work again.
Might be something you need to do in the mimeapps.list.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
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.
Last edited by GNUser (2017-06-29 20:08:50)
Offline
hmmm, I can't figure it out, the only way I can even reproduce your issue is unchecking that box in preferences.
Maybe check /home/(user)/.config/mimeapps.list, I have this entry in mine:
inode/directory=caja-folder-handler.desktop
Maybe that will help?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Just a shot in the dark here, but could it be an artifact of removing the systemd dependencies? It was almost a year ago that systemd started automounting usb drives:
https://www.theregister.co.uk/2016/08/2 … ount_tool/
I am not sure how to test this for systemd stuff though, I will say that when using usb drives on my distros that still have systemd I always unmount the usb drive via command line before I try to make any changes like formatting or repartitioning or using dd. If I don't I always run into trouble of some sort. Of cource that also means I need to replug the usb drive or manually mount it when I am done.
Hope that helps in some way.
lazlo
Last edited by lazlo (2017-06-29 20:11:56)
Offline
Just a shot in the dark here, but could it be an artifact of removing the systemd dependencies?
lazlo
Nope. I'm running the exact same system. And just tested another Devuan Mate install, everything working correctly.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
@greenjeans: I tried adding "inode/directory=caja-folder-handler.desktop" and no joy. I also tried "inode/directory=caja.desktop" just for kicks and no luck either.
@lazlo: Good ideas. I tried the same USB drives in Debian 8 and got same results (some auto-open and others don't), so I don't think this is systemd-related. Also, I always unmount the drives before attempting to reformat in GParted (besides, I think GParted would refuse to format a drive that's mounted).
I'm sure that some subtle difference between a thumbdrive from factory vs. one formatted in GParted is to blame for this...
P.S. Sorry for making a big deal out of such a minor issue. It's just that Devuan works so well that at this point this is the only thing about my system that bothers me
Last edited by GNUser (2017-06-29 20:25:09)
Offline
I'm sure that some subtle difference between a thumbdrive from factory vs. one formatted in GParted is to blame for this...
No sir. I literally have 8 different thumb drives with me right now, ALL have been formatted with gparted. Just for giggles I deleted everything on one and unformatted completely, after I did that it wouldn't even automount, much less open. I reformatted to ext3 with gparted, unplugged/plugged and it opened right up. I have probably done a couple hundred usb drives with gparted in the last ten years, trust me, it's not gparted.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Okay I just found another way to reproduce this.
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?
Last edited by greenjeans (2017-06-29 20:47:53)
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
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.
Last edited by GNUser (2017-06-29 21:44:16)
Offline
wow, strange one GNUser......i'm at a loss......
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Me, too. Very mysterious behavior, to be sure.
I'll keep at it when I have time, and will post any new insights here.
Offline
OK, so what happens when (as root) you:
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
Last edited by lazlo (2017-06-29 22:38:43)
Offline
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?
Last edited by GNUser (2017-06-29 23:51:57)
Offline
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.
Last edited by GNUser (2017-06-30 01:24:03)
Offline
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
Last edited by lazlo (2017-06-30 02:27:09)
Offline
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.
Last edited by GNUser (2017-06-30 17:11:09)
Offline
Yay! Glad you guys fixed it, but before you go to all the below steps on any other drive that does this in the future, I was wondering if you had tried just creating a new partition table first before proceeding with formatting? Knowing gparted and thumbdrive weirdness i've experienced in the past, i'd say there was a good chance doing just that might have been what fixed it, not sure you needed to zero it out first.
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.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
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.
Last edited by GNUser (2017-06-30 21:46:45)
Offline
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?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Don't manufacturers sometimes put strange data on flash drives that could be causing this? Maybe some 'security' or MS idiot feature?
Online
In the past I have had flash drives that misbehaved, however it was a different scenario. After using dd to copy an iso image to a drive MS Windows would no longer read, mount, format, or partition the drive until I zeroed the sectors with dd in linux. It is a rare occurrence and it may have been this same issue GNUser had or a related one. I have never been a fan of auto mounting usb drives in any OS for the same reasons I never liked "Boot From Floppy" as the default BIOS option in the old days. It's a good way to get a malware infection if you have ever lost sight of the flash drive. So in linux, I turn off auto mounting of everything by force of habit.
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
Last edited by lazlo (2017-06-30 23:53:54)
Offline
@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.
Last edited by GNUser (2017-07-01 00:02:49)
Offline