Dave Gutteridge dave@tokyocomedy.com wrote:
How do I do that if no icon comes up, or there is no place to browse within the file system? If there is some location that I'm supposed to know of where the SD card should have shown up, then please let me know where that is.
Dave:
This is one area where UNIX and Windows differ, and I must say, UNIX is _much_safer_. I'll explain (to other people: killfile me if you want).
- Buffering, Caching, Commits and Applications ...
With read-only CDs (CD-ROM/R) and DVDs (DVD-ROM/R), this hasn't been much of an issue on Windows. Once you start using rewritable media, it comes a real issue. Some CD rewritable programs mititgate it for CD-RW, DVD-RAM/RW/+RW, but the "old floppy issue" that cost companies billions in lawsuits is starting to plague USB devices again.
It's not the drives or media, but the OS' approach.
When you access a re-writable device in an OS, the OS begins to cache information. As long is it is read-only, it is typically okay. If you're just copying files, you're typically okay.
Once you start writing to the device, buffers are filled in memory before the data is actually committed to the device. If there is advanced caching operations, this can be even dozens of seconds, especially on slow Electrically Erasable Programmable Read-Only Memory (EEPROM aka "Flash"). If we didn't do that, you're system would _crawl_ as it would have to commit data continuously -- especially to slow floppies, EEPROM and, although to lesser extent in newer products, optical drives.
The problem with most Windows applications, as Visual Studio creates them by default (among other development suites), is that they believe they always have write access to any location (SIDE NOTE: as well as a "default directory" -- a key difference in UNIX/Windows security, UNIX only assumes write access to a user home directory). So even if you're just reading photos in a viewer, many times it opens the file read/write. It could also be storing temporary files if the developer wasn't paying attention to detail. And Windows itself doesn't have mechnisms to disable some buffering/cache functions (I needed to do so for a military application -- result: we couldn't use Windows NT/2000 at the time).
Like floppy drives before it, Microsoft does _not_ have a formal "unmount" function that guarantees buffers/cache will be flushed. Not only that, but Microsoft _always_ mounts things when they are first inserted as of MS-DOS 7.x (Windows 95+), and _always_ re-write if possible. As such, the filesystem could be left in an inconsistent state. And as we all know, FAT12/16/32 is not very recoverable, and data is typically lost -- sometimes totally corrupted if it is not flushed and consistent.
As such, it's highly recommended you disable "auto-launch" for this reason. Prior to Windows, MS-DOS wasn't too bad because even SMARTDRV.EXE would only "read-cache" for floppy disks, meaning that it _always_ committed to disk immediately. But under MS-DOS 7 (Windows 95/98/Me) and MS-NT (Windows NT/2000/XP), the OSes no longer do this and use the logic as above.
- UNIX formalizes mount/unmount
In the UNIX world, this is why we use a formal mount and unmount. We don't want to mount something until we're ready to use it (and possibly modify it) and, more importantly, we want to make sure that we flush the buffers and leave the disk consistent. UNIX also offers a "read-only" mode, something that Microsoft does not. That way you can guarantee the device is _not_ modified, even if a read/write media.
[ SIDE NOTE: In fact, most Linux distros mount CD/DVD media _explictly_ read-only by default, even rewritable media. If you want otherwise, you have to explictly add another fstab or automounter entry. ]
Now UNIX/Linux _does_ have some "automation" features. There are a few of them (some more "Windows-like" and semi-deadly than others -- especially the GUI services ;-), but in the FC/RHEL/CentOS world, we use the "automounter." It is very useful for many things, but "out-of-the-box," it's typically used for CD/DVDs.
In a nutshell, the automounter (autofs in FC/RHEL/CentOS) is a kernel-level function. When someone enters a directory designated as an automounted directory, the kernel automatically mounts the specified device -- be it a remote network share, a local disk or, in the default cause, the local CD device (if the system has one at install-time).
Automounter also has a "time-out," typically 30 seconds. That means after 30 seconds of inactivity, it will automatically unmount. The device. If you don't want to wait, you can always use the "umount" (no "n") manually, or right click on the icon on your desktop (if it was mounted that way). GNOME (what I use) even has an "applet" on the system trap that let's you "click mount/umount" filesystems (assuming, of course, the user has access to do so in /etc/fstab with the "user" option or another).
Until a device is umount'd, Linux will _not_ allow you to eject it -- at least when the eject is "digital/logical" and not physical. This is also unlike Windows, which gives you the "please put the media back in b'tch" non-sense even when you don't understand why (something UNIX, let alone Macs, avoid nicely ;-).
Unfortunately, that doesn't stop the problem when drives allow you to "physically eject" or "pull out" such as floppy drives (except on a Mac) or EEPROM card readers. If you don't umount, expect corruption, just like Windows users run into regularly. The difference between Windows and UNIX is that there is a formal "umount" function -- be it manual, or automated with something like automounter and its timeout.
For UNIX die-hards, we _hate_ the concept of automatically mounting removable media. That's why I disable the CD recorder for automount -- both at the kernel (via autofs) and GUI levels (GNOME, KDE, etc...).