[vox-tech] how to access the content in the usb flash

Wed Jul 12 04:32:03 PDT 2006

Thanks to both Pete and Ken!
Ken, I appreciate your long and detailed explaination, which is very
helpful and I made it by following the instructions. of cause there is
a lot for me to digest yet. :)

Hai

On 7/12/06, Ken Bloom <kbloom at gmail.com> wrote:
> On Tuesday 11 July 2006 22:16, Hai Yi wrote:
> > Hello there:
> >
> > I have a creative flash with a usb port, after I plugged it in the
> > port, I see this:
> >
> > $ lsusb
> >
> > Bus 003 Device 004: ID 041e:4139 Creative Technology, Ltd
> > Bus 003 Device 001: ID 0000:0000
> > Bus 002 Device 001: ID 0000:0000
> > Bus 001 Device 004: ID 06cb:0003 Synaptics, Inc.
> > Bus 001 Device 003: ID 045e:0053 Microsoft Corp.
> > Bus 001 Device 001: ID 0000:0000
> >
> > Then I issued a command (might be wrong)
> > mount -t usbfs /proc/bus/usb/003/004 /mnt/
> >
> > Then I am struck in the middle of nowhere, don't know how to proceed
> > to access the content in my flash.
>
> # umount /mnt
>
> While what you tried seems like a very logical command, it's really the
> completely wrong tack, for several reasons:
>
> a) lsusb doesn't give you the information you need to mount the drive
> b) /proc/bus/usb/003/004  isn't a device node
> c) usbfs isn't a way of accessing data on a USB device.
>
> A device node is a special kind of file living somewhere in /dev that
> when read from or written to, passes through the device driver and
> actually talks to the device.
>
> The information you're looking for when you mount a device is actually
> printed by the kernel when you attach the device. If you're using X
> window, then you won't see it, but no worries. You can always see the
> log of kernel messages by typing dmesg (as a normal user). Here's the
> relevant portion of my dmesg when I attach my thumb drive:
>
> usb 1-1: new full speed USB device using uhci_hcd and address 2
> usb 1-1: configuration #1 chosen from 1 choice
> SCSI subsystem initialized
> Initializing USB Mass Storage driver...
> scsi0 : SCSI emulation for USB Mass Storage devices
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before scanning
>   Vendor: SanDisk   Model: U3 Cruzer Micro   Rev: 2.15
>   Type:   Direct-Access                      ANSI SCSI revision: 02
>   Vendor: SanDisk   Model: U3 Cruzer Micro   Rev: 2.15
>   Type:   CD-ROM                             ANSI SCSI revision: 02
> usb-storage: device scan complete
> SCSI device sda: 990865 512-byte hdwr sectors (507 MB)
> sda: Write Protect is off
> sda: Mode Sense: 03 00 00 00
> sda: assuming drive cache: write through
> SCSI device sda: 990865 512-byte hdwr sectors (507 MB)
> sda: Write Protect is off
> sda: Mode Sense: 03 00 00 00
> sda: assuming drive cache: write through
>  sda: sda1
> sd 0:0:0:0: Attached scsi removable disk sda
>
> The relevant line is the following:
>  sda: sda1
> this line is the list of device files corresponding to the partitions on
> the thumb drive. (Yes, you can have multiple partitions)
>  * sda is the device file corresponding to the whole drive.
>  * the drive has one partition, named sda1.
> You want to mount sda1. The device files are found in /dev, so you want
> to issue some variant of the command "mount /dev/sda1 /mnt"
>
> usbfs is completely the wrong filesystem type. It's simply an
> informational filesystem[1], kinda like proc (mounted on /proc) or
> sysfs (mounted on /sys) that doesn't contain any real data on any disk.
> It also doesn't take a device name. Actually, it takes a path to a
> device and completely ignores it, not even bothering to check that it
> exists, so by convention something like "none" or "usbfs" is used.
> However, when you told it that /proc/bus/usb/003/004 was the device
> file, that was allowed too. It completely ignored it and mounted the
> informational filesystem on /mnt (and didn't spew out any error
> messages because you hadn't actually done anything wrong from the
> system's point of view).
>
> The filesystem on your flash drive (unless you reformatted it) is of
> type vfat. So the correct, fully specified command would be "mount -t
> vfat /dev/sda1 /mnt". It's not actually necessary to specify the
> filesystem type though -- the kernel can autodetect the file system
> type, so the command I gave before ("mount /dev/sda1 /mnt") would also
> work just fine.
>
> But there's a better way to mount this...
>
> You have to run the mount command as root (which I'm sure you did) to
> mount a usb device. This is becuase when USB devices came along, they
> completely broke the kernel's old way for users to mount their own
> disks. Back in the days of floppies, a device always had the same
> device nodes. When you inserted a floppy disk, you *knew* that it's
> device node was /dev/fd0. USB changed all that. Since you could now
> plugin as many USB devices as you wanted, in as many orders as you
> wanted, and they all showed up as SCSI disks (/dev/sd*), they began to
> move around. The old method of specifying a device that users could
> mount in /etc/fstab broke, because now there were many devices.
>
> So the distributions created pmount. A user in the plugdev group can
> mount a USB device to a mountpoint in /media in a very simple
> way: "pmount /dev/sda1" (replacing, of course the device name with the
> one you discovered above using dmesg). The mountpoint on which this is
> mounted is /media/sda1. When you're ready to unmount the device, you
> use the command "pumount sda1". Now you don't need to be root.
>
> But IMO, this system still sucks because you still need to discover the
> right device file on your own[2]. udev has some techniques to always
> guarantee the same device name, but that doesn't work in general
> because it only works for USB keys that the system administrator
> configures the system to know about in advance. If you went to a public
> computer lab and tried, you'd be SOL.
>
> Looking around, I see a Debian package which may help:
> [bloom at cat-in-the-hat ~]$ apt-cache show usbmount
> Package: usbmount
> Priority: extra
> Section: admin
> Installed-Size: 116
> Maintainer: Martin Dickopp <martin at zero-based.org>
> Architecture: all
> Version: 0.0.14-0.1
> Depends: udev (>= 0.084-2), lockfile-progs
> Filename: pool/main/u/usbmount/usbmount_0.0.14-0.1_all.deb
> Size: 10494
> MD5sum: 1b74998193fe32a6e05eca5232e605db
> SHA1: d52ca0d42689842f6b9e977d8c4ef02f1cbbff53
> SHA256: 950c4dd2ca67dc8daefff22242db2cecf2aac87169cd9259f64c8648fa11b3c9
> Description: automatically mount and unmount USB mass storage devices
>  This package automatically mounts USB mass storage devices (typically
>  USB pens) when they are plugged in, and unmounts them when they are
>  removed. The mountpoints (/media/usb[0-7] by default), filesystem types
>  to consider, and mount options are configurable. When multiple devices
>  are plugged in, the first available mountpoint is automatically
>  selected. If the device provides a model name, a symbolic link
>  /var/run/usbmount/MODELNAME pointing to the mountpoint is automatically
>  created.
>  .
>  The script that does the (un)mounting is called by the udev daemon.
>  Therefore, USBmount requires a 2.6 (or newer) kernel.
>  .
>  USBmount is intended as a lightweight solution which is independent of
>  a desktop environment. Users which would like an icon to appear when an
>  USB device is plugged in should use the pmount and hal packages
>  instead.
>  .
>  Homepage: http://usbmount.alioth.debian.org/
> Tag: admin::configuring, admin::filesystem, hardware::storage,
> hardware::usb, interface::daemon, role::sw:utility, use::configuring
>
> This looks better still, but I'm still not sure it's the ultimate
> solution. Your USB device comes up on some random mountpoint in /media
> and you may need to run ls on several of those mountpoints to find your
> device. And /var/run/usbmount/MODELNAME, while innovative, probably
> isn't the best idea either -- if you replace your USB key with one by a
> different brand (e.g. if you lost the first one, and a different brand
> was cheaper this time) then MODELNAME would change and you'd have to
> discover *that* all over again.
>
> I think the solution would be to create a command like "waitmount
> $LABEL" where you run the command *before* you plug in the device, and
> waitmount would sit around waiting for you to plug in the device. As
> soon as you plugged it in, it would mount the device at ~/$LABEL
> (possibly creating the mount point if it didn't already exist). Anyone
> have any better ideas? I'd really like to hear something that would
> work similarly to the way mounting floppies and CD-roms does. Having
> lots of different mount commands to memorize seems to be not so fun,
> and a recipe for confusion.
>
> --Ken Bloom
>
> [1] http://www.cs.indiana.edu/~bpisupat/work/usb/node14.html
> [2] Your desktop environment can discover the device file of the new
> device and use pmount to mount it and do other nice things like create
> a desktop icon. That's actually pmount's real reason to exist. But if
> that's what you wanted to do, you'd have done it already and you
> wouldn't be asking this question.
>
> --
> I usually have a GPG digital signature included as an attachment.
> See http://www.gnupg.org/ for info about these digital signatures.
>
>
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>
>
>
>