This occasionally happens to me when I've been editing an OOo document that resides on a flash drive I use with one of my laptops. I've tried poking around in ps to find out which process has the drive locked, and I can't figure it out. Nothing directly refers to the flash drive except one of the hald processes, and it's just scanning the drive (I tried killing that and it made no difference).
My usual sequence of events is as follows:
1. Plug in the flash drive. 2. Wait for it to appear on the desktop. 3. Start up a terminal window (which recognizes the flash drive and runs sudo to allow execute permissions on the drive). 4. Run the script that unzips the files I want. 5. Open the file with the OO writer, edit it for a while, then save and close it. 6. Update the zip archive (on the flash drive). 7. Close the terminal window. 8. Umount the drive, which fails.
I've tried waiting for as much as five minutes, running sync - nothing. The last three times this happened, I had to shut down the laptop (which I was going to do anyway) in order to free the flash drive. This takes several minutes, which can be precious when I need to bag the laptop in a hurry.
There's nothing in any of the syslogs. The laptop was just updates to the L&G CentOS 5.5.
What am I missing?
Thanks.
mhr
MHR wrote, On 05/20/2010 08:38 PM:
This occasionally happens to me when I've been editing an OOo document that resides on a flash drive I use with one of my laptops. I've tried poking around in ps to find out which process has the drive locked, and I can't figure it out. Nothing directly refers to the flash drive except one of the hald processes, and it's just scanning the drive (I tried killing that and it made no difference).
<SNIP>
What am I missing?
when next it happens, you might try (note, you are playing with a root tool, it may or may not work as a normal user): /sbin/fuser -m /media/myFlashDrive/ or /usr/sbin/lsof /media/myFlashDrive/
What can be *really* frustrating, is when those commands (with any options) don't give any info, and you cant get it unmounted (granted I have not seen that since using Fedora 1 machines with DRBD as an NFS server).
man fuser "-m ... All processes accessing files on that file system are listed. ..."
man lsof
----- Original Message ----
From: MHR mhullrich@gmail.com To: CentOS mailing list centos@centos.org Sent: Thu, May 20, 2010 7:38:19 PM Subject: [CentOS] Can't umount flash drive because an application has it locked
This occasionally happens to me when I've been editing an OOo document
that
resides on a flash drive I use with one of my laptops. I've
tried
poking around in ps to find out which process has the drive
locked, and I
can't figure it out. Nothing directly refers to the
flash drive except
one of the hald processes, and it's just scanning
the drive (I tried killing
that and it made no difference).
My usual sequence of events is as
follows:
1. Plug in the flash drive. 2. Wait for it to appear on the
desktop.
3. Start up a terminal window (which recognizes the flash drive
and
runs sudo to allow execute permissions on the drive). 4. Run the
script that unzips the files I want.
5. Open the file with the OO writer,
edit it for a while, then save
and close it. 6. Update the zip archive (on
the flash drive).
7. Close the terminal window. 8. Umount the drive, which
fails.
I've tried waiting for as much as five minutes, running sync
nothing. The last three times this happened, I had to shut down
the
laptop (which I was going to do anyway) in order to free the
flash
drive. This takes several minutes, which can be precious when I
need
to bag the laptop in a hurry.
There's nothing in any of the
syslogs. The laptop was just updates to
the L&G CentOS
5.5.
What am I
missing?
Thanks.
mhr
to me it sounds like the zip program is culprit since it might still holding onto the flash file system. did you try fuser -l on the flash drive and see what has a hold on it. just a thought.
On Thu, May 20, 2010 at 6:34 PM, Steven Vishoot sir_funzone@yahoo.com wrote:
to me it sounds like the zip program is culprit since it might still holding onto the flash file system. did you try fuser -l on the flash drive and see what has a hold on it. just a thought.
I'd have to check next time on both, but unless the zip program uses a daemon, which I've never heard of, I wouldn't think it's that. Didn't try fuser (or lsof). Will next time.
Thanks.
mhr
On 05/20/2010 09:00 PM, MHR informed us:
On Thu, May 20, 2010 at 6:34 PM, Steven Vishootsir_funzone@yahoo.com wrote:
to me it sounds like the zip program is culprit since it might still holding onto the flash file system. did you try fuser -l on the flash drive and see what has a hold on it. just a thought.
I'd have to check next time on both, but unless the zip program uses a daemon, which I've never heard of, I wouldn't think it's that. Didn't try fuser (or lsof). Will next time.
Thanks.
mhr
Another thought: I have been known to cd to the directory on the flash drive containing the files to be copied, usually when I'm selectively copying a number of files. Advantage is that you can easily copy/paste the file name(s). Down side is that you've got to remember to cd out of the flash drive before it'll umount.
On Thu, May 20, 2010 at 9:35 PM, Robert kerplop@sbcglobal.net wrote:
Another thought: I have been known to cd to the directory on the flash drive containing the files to be copied, usually when I'm selectively copying a number of files. Advantage is that you can easily copy/paste the file name(s). Down side is that you've got to remember to cd out of the flash drive before it'll umount.
The way I do that is usually to close the terminal window, which removes the process that's cd'c to the drive.
I don't do this daily, so it may be a few before I can nail it down.
Thanks.
mhr
-
MHR -
Robert -
Steven Vishoot -
Todd Denniston