Dave Gutteridge <dave@xxxxxxxxxxxxxxx> 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...).
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
