Jump to content

Safely Eject Gps


Recommended Posts

Since updating all our laptops and main Desktop to windows 10 almost every time I try to remove my Gps'rs I get a message that its still in use and can not be removed. End result is I have to shut down the laptop to disconnect my Gps unit. I have done an internet search but can not find a fix but found it is a very common problem with usb devices.

What is everyone else doing to disconnect their Gps'rs - shutting down the laptop is not fun when there is 3 or 4 Gps'rs to do.

Link to comment

Since updating all our laptops and main Desktop to windows 10 almost every time I try to remove my Gps'rs I get a message that its still in use and can not be removed. End result is I have to shut down the laptop to disconnect my Gps unit. I have done an internet search but can not find a fix but found it is a very common problem with usb devices.

What is everyone else doing to disconnect their Gps'rs - shutting down the laptop is not fun when there is 3 or 4 Gps'rs to do.

It happens to me very occasionally. If some program is using the USB drive (the GPSr), that can cause the issue. For example, if the computer has been set to open a particular program when the drive is connected, that can cause it. And that program might be misbehaving, or probably doesn't even need to be accessing the drive.

 

If you'd enjoy a lot of heavy reading, here are some good articles about it:

http://www.pcworld.com/article/2927972/when-windows-refuses-to-eject-mass-storage-5-ways-to-safely-remove-a-usb-drive.html

 

http://knowledge.seagate.com/articles/en_US/FAQ/205071en

Link to comment

I used to build OSes in a former life. The USB stack was one of my projects. I can't get behind the advice above to just ignore it, but since I'm not a Windows guy, I also can't tell you how to get past it. I can only encourage you to dig deeper.

 

In the beginning, disks were attached to computers and couldn't be powered off independently. So it was OK to have stuff in memory that was on the way to the disk to make it consistent. Think of it as an "IOU" to magnetic media. Magnets came and went and went. Hotplug came and stayed. OSes that were designed to hold things in RAM eventually learned to aggressively retire transactions to permanent storage when the busses were otherwise idle because people WANTED to rip the devices from their machines and got grumpy when you were deemed responsible for corrupting the data on that device. Around the turn of the century, OSes learned to treat removable media as "special", even at some performance cost.

 

IMO, if you're getting that message from your OS in modern times, it's because your OS _knows_ there is data that the OS is holding that has not been retired to the device. It might not matter today and it might not matter tomorrow, but you're only going to get lucky so many times.

 

I encourage you to find what's using that device and to tell it "hey, this device is going away, you need to settle your check with the cashier NOW." before you eject it or rip the cable out.

 

 

Link to comment

I used to build OSes in a former life. The USB stack was one of my projects. I can't get behind the advice above to just ignore it, but since I'm not a Windows guy, I also can't tell you how to get past it. I can only encourage you to dig deeper.

One of the sneaky things that happens when a drive is connected, is the least useful bloatware pops up and asks to manage the drive. "Would you like to always open this media in Photos?", or whatever. If I'm in a hurry or not paying attention, I might select the worst option as my default. And from then on, the program is accessing the USB drive once it's connected.

Link to comment

Since updating all our laptops and main Desktop to windows 10 almost every time I try to remove my Gps'rs I get a message that its still in use and can not be removed. End result is I have to shut down the laptop to disconnect my Gps unit. I have done an internet search but can not find a fix but found it is a very common problem with usb devices.

What is everyone else doing to disconnect their Gps'rs - shutting down the laptop is not fun when there is 3 or 4 Gps'rs to do.

You could take a look at the programs that run when you plug in a GPSr (a USB Drive). This is called "Autoplay". If there's software accessing your GPSr by default, it may cause your problem. When you install software, one thing it typically does is ask to take over various things for your convenience. Maybe there's a rogue piece of software accessing your USB Drives, and you can tell it to stop that. Worth a look?

 

See the heading "How to Change Your AutoPlay Defaults" here:

http://www.makeuseof.com/tag/change-default-settings-windows-10/

 

See what the setting is for "Removable Drive". I have mine set for "File Explorer", but if it's anything else, suspect that as the culprit. Another option is to set it to "Take No Action", in which case, you'll use the File Explorer from the Start Menu instead.

Edited by kunarion
Link to comment

Macs and Linux have mechanisms to force eject a drive if it becomes "sticky." I would hope that MS has included such a feature into windows by now. Generally, it's a good idea to eject any peripheral devices before detaching as it can lead to data and even file system corruption on the device should it be in the process of reading/writing at the time of disconnecting it. Most of the time, it should be safe to do without ejecting it from the OS first.

Link to comment

I've never ejected a USB device, ever. Never, ever has it caused a problem, whether it was in the middle of a file transfer or not.

I did, at first. I would load Pocket Queries to my Garmin Oregons, and although Windows could access the file on the devices, the GPSrs would show no caches. Not often, but almost always when I was in a hurry. At the time, it was suggested that the files hadn't properly closed, and that "Eject" may be a solution. I still never bother to "Safely Eject", but I do wait a lot longer before disconnecting the USB cable. I don't know if the issue was even related to files "not closing". But I have had no invisible PQs since I started the practice. So something improved for sure.

Edited by kunarion
Link to comment

I've never ejected a USB device, ever. Never, ever has it caused a problem, whether it was in the middle of a file transfer or not.

Ugh. Try that after sending (I'm using GSAK) caches to an Oregon 450 (though it's not the only model where this is a potential issue). Nothing worse than being out on the road and ready to cache and then find the unit reporting "No geocaches found". Others here have reported similar experiences at times. After burning myself twice that way, I've always done two things. First, I do try to do a logical before physical disconnect. Second, I always check to see if I can pull up any caches after sending them to the unit and before heading out on a caching run.

 

It's unclear to me why this is the sort of problem it is for some Garmin units. If it were a matter of flushing a cached write to the unit, I could understand how that might be an issue, but often, the device is connected for a considerable time after the write and before the physical disconnect. Shutting the unit off and turning it on doesn't improve the "No geocaches found" situation. Viewing the device's GPX folder, any uploaded *.gpx files can be found intact. Sometimes something odd just happens when performing a physical disconnect without a logical disconnect first.

Link to comment

What happens when you yank out the USB cable connecting your GPS to the PC depends in part on how you've set up the USB options in Windows.

 

Safely Remove USB Drives Just by Unplugging Them

 

The article was written for Windows 7, but the information is also valid for previous versions of Windows and Windows 10 with a couple of minor tweaks.

 

Bottom line, whether it's safe to just yank out the cable depends on how the USB options in your copy of Windows are set.

 

--Larry

Link to comment
I always check to see if I can pull up any caches after sending them to the unit and before heading out on a caching run.

I haven't had an issue since I had a Garmin Oregon 450, but I still check that there are some choice caches in the list I loaded. Just in case. Yeah, it's bad to drive 50 miles and then notice there are no caches shown. :anicute:

 

But I'm also WAAAY to lazy to bother with "Safely Eject" (nor to change such Windows settings for the purpose). I wait a couple of minutes, then unplug it, and all is well. I have to check if the cache has just now gotten an FTF log anyway. :ph34r:

Edited by kunarion
Link to comment

I've never ejected a USB device, ever. Never, ever has it caused a problem, whether it was in the middle of a file transfer or not.

Ugh. Try that after sending (I'm using GSAK) caches to an Oregon 450 (though it's not the only model where this is a potential issue).

 

I always use GSAK and my Or600 (Colorado300 before that), never "safely ejected" my GPS, USB storage or anything else USB. No problems whatsoever (Win7).

Link to comment

What happens when you yank out the USB cable connecting your GPS to the PC depends in part on how you've set up the USB options in Windows.

 

Safely Remove USB Drives Just by Unplugging Them

 

The article was written for Windows 7, but the information is also valid for previous versions of Windows and Windows 10 with a couple of minor tweaks.

 

Bottom line, whether it's safe to just yank out the cable depends on how the USB options in your copy of Windows are set.

 

--Larry

My system has always been set for "Optimize for quick removal" for the internal memory of the 450, and that's where I park my weekly *.gpx caching file. HOWEVER, I would point out that the installed uSD card can't be set up this way. Windows grays out the "Optimize for quick removal" option for the uSD card properties, and instead forces "Optimize for performance" with the "Enable write caching on the disk" defaulted for the uSD card. What's confusing about THAT setting (and again, it shouldn't bother my internal memory writes to the 450) is that the radio button and check box appear to be redundant.

 

The radio button reads "Optimize for performance -- This setting enables write caching in Windows to improve disk performance. To disconnect this device from the computer, click the Safely Remove Hardware icon in the taskbar notification area".

The 'sub' check box below the above reads "Enable write caching on the disk -- This setting enables write caching to improve disk performance, but a power outage or equipment failure might result in data loss or corruption."

 

As far as I can see, both seem designed to either enable or disable write caching to the device. The former can't be modified. The latter can be deselected, but given the reading of the radio button, what does deselecting the checkbox actually accomplish?

 

However, and again, this is only for the uSD card in the unit. The unit's own internal memory is set up for "Optimize for quick removal".

Link to comment

As suggested it turns out something is still running keeping me from ejecting the Gps unit (thanks robertlipe)

I decided to try a program called "Usb Safely Disconnect" (thanks for the info kunarion)to help me find out which

program was holding things up. It did find the offending file but took 20 minutes to get the safe to disconnect

message. Its much faster to shut down my laptop and disconnect then restart and do again for the next Gps'r.

After switching to Windows 10 I also changed how I backed up my Home Network - I am using the backup software

that came with my Netgear router to continuously backup all my PC and laptops - and that appears to be where the

problem is coming from.

So now I have to find a way to set my USB ports to not backup - I have been trying to exclude that offending

file from the backup but it is a file being used by my backup system so no luck yet.

Maybe the easy way is just not use the Netgear backup utility and use the one that comes with Windows 10

Thanks for all your help - its been educational.

Link to comment

I've never ejected a USB device, ever. Never, ever has it caused a problem, whether it was in the middle of a file transfer or not.

Ugh. Try that after sending (I'm using GSAK) caches to an Oregon 450 (though it's not the only model where this is a potential issue).

 

I always use GSAK and my Or600 (Colorado300 before that), never "safely ejected" my GPS, USB storage or anything else USB. No problems whatsoever (Win7).

 

And unless I eject my 450, it starts to load the new files and actually turns itself off about halfway through the process. The screen just fades to gray.

Link to comment

Indeed, the 450 may do a 'halfway hang' some of the time as well. When a new/modified *.gpx file is discovered during boot, and without a logical disconnect, the progress can hang at exactly 50%, after which it's either a lock up at that point or a shut-down of some sort. That's usually indicative of a *.gpx file that can't be indexed for some reason. Have seen that as well as the surprise "No geocaches found" message if I neglect to do the logical disconnect first.

 

It' s not an urban myth, guys ... it happens, and isn't even very hard to replicate if you have the right generation Garmin.

Link to comment

Indeed, the 450 may do a 'halfway hang' some of the time as well. When a new/modified *.gpx file is discovered during boot, and without a logical disconnect, the progress can hang at exactly 50%, after which it's either a lock up at that point or a shut-down of some sort. That's usually indicative of a *.gpx file that can't be indexed for some reason. Have seen that as well as the surprise "No geocaches found" message if I neglect to do the logical disconnect first.

 

It' s not an urban myth, guys ... it happens, and isn't even very hard to replicate if you have the right generation Garmin.

I saw the effect several times on my 450, and after reading the threads, I changed my practice. You know, loading and then not immediately disconnecting and driving 50 miles, in a hurry since I'm late. Instead, I waited a couple minutes before unplugging the USB, and that made a difference. I think the 450 was just plain slower, and I needed to take more care in this matter. But it also happened on my 550, if I lapsed. I have not tempted the Oregon 650. "Patience, Grasshopper". Much, I have learned. Caches in view, I have.

Edited by kunarion
Link to comment

You know, loading and then not immediately disconnecting and driving 50 miles, in a hurry since I'm late. Instead, I waited a couple minutes before unplugging the USB, and that made a difference.

 

That may be the reason I never had any problems just disconnecting any USB stuff. While loading caches and then loading images from GSAK with several macros I'm doing other stuff on my main screen. My GPS is often connected more than half an hour after loading before I realize I still have it plugged in. I never load and dash anyway. Everything is prepared the evening before we go caching.

Link to comment

This download from Microsoft should make sure your external devices (eg GPS) are all completely written before you physically pull the plug. (I'm surprised it's not a built-in part of Windows...) The author is a well-known alpha geek and expert on Windows internals.

 

technet.microsoft.com/sv-se/sysinternals/bb897438(en-us).aspx

 

EDIT to un-bork the link. This forum auto-breaks links with a ) character apparently.

Edited by Viajero Perdido
Link to comment

This download from Microsoft should make sure your external devices (eg GPS) are all completely written before you physically pull the plug.

I don't know if anyone has proven that it's all about "safely ejecting", but the evidence is that it's at least time related. One thing the Garmin Oregon does is catalog all the caches into a database as they are loaded. Wait a little longer to unplug the cord, and viola, no more problem. The 450 (and then the 550) was perhaps a leetle slower at this than everyone expected. It's acceptable, but a thing to bear in mind if you're always in a frantic rush to get out there and cache like I know I am.

 

The reason I wondered about the "unclosed file" theory is, Windows is way picky about files needing to be just right before it will open them. So Garmin not being able to read the file, yet Windows can, that makes me suspicious. We can go with that, no problem. But in case it pops up again, keep in mind that "closing files" may just be part of the picture.

Link to comment

I don't know if anyone has proven that it's all about "safely ejecting", but the evidence is that it's at least time related. One thing the Garmin Oregon does is catalog all the caches into a database as they are loaded. Wait a little longer to unplug the cord, and viola, no more problem. The 450 (and then the 550) was perhaps a leetle slower at this than everyone expected. It's acceptable, but a thing to bear in mind if you're always in a frantic rush to get out there and cache like I know I am.

It might be the power switch from USB to internal while the GPS is indexing the data could cause file corruption.

Link to comment
It might be the power switch from USB to internal while the GPS is indexing the data could cause file corruption.

I think so. Or a combination of things. A series of unfortunate events. :anicute:

 

I guess we'll have a better understanding if the problem, if a lot of people get their PCs set up to "Automatic Safely Eject", and yet the problem continues.

Edited by kunarion
Link to comment
I don't know if anyone has proven that it's all about "safely ejecting", but the evidence is that it's at least time related.

Time is certainly a factor. If you rip the cable out while data has been written, but the free list hasn't been updated, it's probably benign. If the free list has been updated, but the directory hasn't been updated, you've "just" lost free space on the volume. The next fsck or chkdsk or other "reconcile the books" utility can work that out. If all the writes have been retired, it's _probably_ fine; the forensic cases are down to the exact order. If the directory had to grow and you've updated the end pointer to a block but not written that block yet or the new block is going to be removed from the free list in the next opcode[1], Very Bad Things will happen. (This is also why SWEs have to think about things like the drive controller's firmware "helpfully" reordering your writes in the name of performance or wear leveling.) It's a battle of microseconds. red90's been lucky. I've been paid to design this kind of thing and hope is not a strategy. (Technically, I suppose it is but it's not one that pays well in the long term.)

 

One thing the Garmin Oregon does is catalog all the caches into a database as they are loaded. Wait a little longer to unplug the cord, and viola, no more problem.

The Oregon's processor does not access the filesystem while the USB storage is being written by the host. This is why the device goes catatonic when you plug it into a computer. (Yes, I know about the serial PVT/NMEA modes.) Filesystems need ONE arbiter of communications with it; if you have two uncooperating devices (think about networked computers, only this is the ARM in your Garmin and your host) that can each read and write shared data structures at the same time, someone WILL corrupt the free list or the directory or whatever. This is why mass storage mode on phones and cameras is such a landmine - it's solved on those devices by using MTP or PTP so there's one arbiter talking to file store and a well defined communications protocol with the other devices that operate at the "here's a file" level instead of scribbling straight to sectors and blocks. It's like a tiny little Netware/NFS/Samba server in your pocket. See discussions like http://www.howtogeek...b-mass-storage/ if this kind of thing interests you. It covers the various solutions without getting too nerdy into why a shared FAT volume just doesn't work.

 

Once the computer has declared it's done (or the cable has been ripped out) the Garmin will scan the GPX directories looking for changes. It's at that time that it updates the internal database. That's also why that first boot after you copy a load of GPX files to is is so slow - it's then that it's parsing the GPX, seeing if anything has changed, and updates the records in what is presumably a sqlite3-like substance.

 

The 450 (and then the 550) was perhaps a leetle slower at this than everyone expected.

The 4x0's (indeed, all the earlier Garmins) were full speed devices, not high speed devices. This is why they're less agonizing to access and the windows of time are smaller. http://arstechnica.c...2003/10/2927-2/

 

Given how often a Garmin won't boot after you copy GPXes to it, the "unplug and drive 50 miles" strategy is worth a few extra minutes to do a safe eject AND verify that the stupid thing will boot and show the caches on the map before you leave your computer. It might still crash when you open specific caches or crash because it crashes - problems Garmin's not gotten under control since shipping the original Colorado - but it's worth it to me to prepare to hedge that bet.

 

My script that unzips the GPXes and puts the -wpts and geocaches in the right place does a sync and asks me if I want to eject the volumes. (My devices have an SD card, so there are two; I use the SD card so if the device has an allergic reaction to the newly copied files, I can remove the card and not have to remember which corner of the screen is needed for a factory reset...while I'm standing in the woods.)

 

We are (I am?) veering off charter for geoaching, but firmly into "and technology." Like eating food off the floor is USUALLY OK, sometimes it's not and there are concrete reasons why. It's not magic or luck.

 

[1] Writing this stuff to work MOST of the time isn't terribly difficult. Writing stuff that's resilient in light of all the retries and reordering that can happen at levels below you while someone is ripping out cables or you've hit a bump and lost connection to the batteries -even momentarily- is Really Hard.

Link to comment

I don't know if anyone has proven that it's all about "safely ejecting", but the evidence is that it's at least time related. One thing the Garmin Oregon does is catalog all the caches into a database as they are loaded. Wait a little longer to unplug the cord, and viola, no more problem. The 450 (and then the 550) was perhaps a leetle slower at this than everyone expected. It's acceptable, but a thing to bear in mind if you're always in a frantic rush to get out there and cache like I know I am.

It might be the power switch from USB to internal while the GPS is indexing the data could cause file corruption.

Except the GPS does not index the data until it is power cycled and 'discovers' the new *.gpx file(s) upon power up. That's what the 2nd half of the progress bar is indicating when it occurs after power up.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...