usb-mount (hotplug + desktop hooks)

usb-mount (hotplug + desktop hooks)

[David Brownell]

I happened across this the other day:

   http://users.actrix.co.nz/michael/usbmount.html

Take hotplug, add scripts and "sudo", and the device
appears magically on your desktop.

Comments?

- Dave



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Oliver Neukum]

Am Samstag, 26. Oktober 2002 01:46 schrieb David Brownell:
> I happened across this the other day:
>
>    http://users.actrix.co.nz/michael/usbmount.html
>
> Take hotplug, add scripts and "sudo", and the device
> appears magically on your desktop.
>
> Comments?

The obvious one. It's a race for the same reason usbd
was racy.
The hotplug invocation is not serialised for starters.
There are other problems as well.
It's a very useful hack for a PC, but it's not a generic
solution for a multiuser system.

Besides, it's not new. The same was done with devfsd
a long time ago, if that subsystem may be mentioned
here.

	Regards
		Oliver



-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Gary_Lerhaupt]

I am especially intrigued by the idea of desktop hooks for when a usb event
(or any hotplug storage event) occurs.  I think this could be used in
conjunction with devlabel rather nicely.  His original reason for not
touching /etc/fstab is because of the changing /dev/sd names.  Devlabel
takes care of this and might also now mitigate his fears for including the
symlink reference in /etc/fstab.

From there, his scripts could be used to create the desktop hooks.  So,
basically, in your agent script you have:
...
[ -x /usr/sbin/devlabel ] && /sbin/devlabel restart
[ -x usb-mount ] && usb-mount
...

Michael, if you're looking for devlabel, it can be found at:
http://domsch.com/linux/devlabel

Gary Lerhaupt
Linux Development
Dell Computer Corporation



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

Hi Gary,

I tried two of the same device, devlabel's scsi_unique_id utility returns
the same ID for both:

model: Neodio TNeodio/Leadtek W
page83: No page83 information found.
page80: 1f00

I was originally going to used the usb-serial as an id, but this isn't 
always implemented. And even when it is, the usb-serial may not remain 
constant for the same device. For example my devices adds the current 
bus-id to the serial, so it differs every time I plug the device in.

So I've moved away from id's or serials.  However, I could create generic fstab
entries like generic-usb-1, generic-usb-2 - but I can't see any advantage.

I guess these devices are similar to floppies, they are generic, if they have 
any ID it will be in the form of a volume label. 

   In case this needs some context - this is about a solution I'm using to
   pop usb-devices onto the KDE desktop - you can see the details at:
           http://users.actrix.co.nz/michael/usbmount.html

Michael

On Tue, 29 Oct 2002 10:52, Gary_Lerhaupt@Dell.com wrote:

> I am especially intrigued by the idea of desktop hooks for when a usb event
> (or any hotplug storage event) occurs.  I think this could be used in
> conjunction with devlabel rather nicely.  His original reason for not
> touching /etc/fstab is because of the changing /dev/sd names.  Devlabel
> takes care of this and might also now mitigate his fears for including the
> symlink reference in /etc/fstab.
>
> From there, his scripts could be used to create the desktop hooks.  So,
> basically, in your agent script you have:
> ...
> [ -x /usr/sbin/devlabel ] && /sbin/devlabel restart
> [ -x usb-mount ] && usb-mount
> ...
>
> Michael, if you're looking for devlabel, it can be found at:
> http://domsch.com/linux/devlabel
>
> Gary Lerhaupt
> Linux Development
> Dell Computer Corporation



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: usb-mount (hotplug + desktop hooks)

[Gary_Lerhaupt]

Are these physically separate USB storage devices made by the same
manufacturer?  Or is this device more like a USB card reader and you are
having problems differentiating between the cards that you put into the
reader?  I have a feeling its the first case, which is unfortunate because
with a bad ID like "1f00" for both, devlabel won't work for you.  Or, at
least it would work for you if you only plugged in one at a time.

If you do go with the one-at-a-time approach, then you could create a
symlink name to be shared by both like /dev/neodio_storage and then go about
automounting with /etc/fstab, etc.  However, this won't work for both at the
same time (as you've seen).

I'm interested in the usb-serial idea, though.   Where are these kept?  Even
if they aren't implemented on many devices, I'd still like to add any
possible identifier to make devlabel work in more scenarios.  You also
mention a volume label, but with USB storage devices, this isn't likely.
Well, at least not on my smart card reader.
-Gary

-----Original Message-----
From: Michael Hamilton [mailto:michael@actrix.gen.nz]
Sent: Saturday, November 02, 2002 5:33 PM
To: Gary_Lerhaupt@exchange.dell.com; david-b@pacbell.net
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: usb-mount (hotplug + desktop hooks)


Hi Gary,

I tried two of the same device, devlabel's scsi_unique_id utility returns
the same ID for both:

model: Neodio TNeodio/Leadtek W
page83: No page83 information found.
page80: 1f00

I was originally going to used the usb-serial as an id, but this isn't 
always implemented. And even when it is, the usb-serial may not remain 
constant for the same device. For example my devices adds the current 
bus-id to the serial, so it differs every time I plug the device in.

So I've moved away from id's or serials.  However, I could create generic
fstab
entries like generic-usb-1, generic-usb-2 - but I can't see any advantage.

I guess these devices are similar to floppies, they are generic, if they
have 
any ID it will be in the form of a volume label. 

   In case this needs some context - this is about a solution I'm using to
   pop usb-devices onto the KDE desktop - you can see the details at:
           http://users.actrix.co.nz/michael/usbmount.html

Michael

On Tue, 29 Oct 2002 10:52, Gary_Lerhaupt@Dell.com wrote:

> I am especially intrigued by the idea of desktop hooks for when a usb
event
> (or any hotplug storage event) occurs.  I think this could be used in
> conjunction with devlabel rather nicely.  His original reason for not
> touching /etc/fstab is because of the changing /dev/sd names.  Devlabel
> takes care of this and might also now mitigate his fears for including the
> symlink reference in /etc/fstab.
>
> From there, his scripts could be used to create the desktop hooks.  So,
> basically, in your agent script you have:
> ...
> [ -x /usr/sbin/devlabel ] && /sbin/devlabel restart
> [ -x usb-mount ] && usb-mount
> ...
>
> Michael, if you're looking for devlabel, it can be found at:
> http://domsch.com/linux/devlabel
>
> Gary Lerhaupt
> Linux Development
> Dell Computer Corporation




-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

Yes they are separate devices - They are two 128MB usb ram-drives.
But the same Neodeo chipset, with the same ID, and maybe the same
serial numbers, appears in other devices like card readers. 

Usb serials can be found in
  /proc/scsi/usb-storage*
and 
  /proc/bus/usb/devices
But I suspect there's a bug in the kernel that forms the entry in
/proc/bus/usb/devices because it doesn't always match the entry
in /proc/scsi/usb-storage* - but I haven't had a chance to look
into this further.

But USB serials seem to be pretty useless because they aren't enforced.
Here's a fragment of a response I received from the linux-usb-users list
that pretty much sums it up.  In particular, note the comment 
about serial numbers not being persistant - which is what triggered
my enquiries.

> From: "Randy.Dunlap" <rddunlap@osdl.org>
> X-X-Sender:  <rddunlap@dragon.pdx.osdl.net>
> To: Michael Hamilton <michael@gentoo.co.nz>
> Cc: <linux-usb-users@lists.sourceforge.net>
> Subject: Re: [Linux-usb-users] Auto mount/unmount: need explanation of serial numbers?
>
> Interesting.
>
> | 1. What part of the serial remains constant for the same device,
> |    if any?
>
> Not part of the USB spec.  This is device-specific behavior.
>
> | 2. Is the serial number the way to recognise the same device
> |    or am I barking up the wrong tree?
>
> The USB spec says that certain USB storage devices (like bulk-only)
> require a serial number and that it is unique for each
> idVendor/idProduct pair and at least 12 digits long.
> Unfortunately I don't see anything in the spec that requires the
> serial number to be persistent (unchanging), which would be
> desirable IMO.
>
> If I were attempting this, I too would have tried to use serial number,
> and eventually someone out there would have run into this problem.
> The larger problem is that there are lots of USB storage devices
> that don't have (or require) a serial number at all.  How are you
> handling those?
>
> -- 
> ~Randy

Things get a little more confusing because, if a usb-device's serial
changes when ever the device is unplugged and replugged, it will 
march down the scsi bus.  For example, plug it in once and
it appears as /dev/sda, unplug it and plug it in again and it will
be /dev/sdb, then /dev/sdc, and so on. I suspect this is because 
the usb-serial keeps changing.  The only way I found to clear this 
up is to unload the usb-storage module.  I'm not sure if the kernel 
can deal with this nicely - because, if it did, I think it would
exhibit bad behaviour for devices that do have a constant serial.
On the other hand, should a device hold onto /dev/sda a week after
you unplugged it just because you haven't rebooted since - I guess
the it should have a lease that times out.  

This is a messy business. I suspect the best that can be done 
is to create a desktop folder where USB devices come and go.  
Each device should named as meaningfully as possible and have 
a tool-tip with as much info as can be retrieved about he 
identity of the device (Manufacturer, Name, etc). But ultimately 
the user must figure out which device is which by inspection.

Yeah - volume labels aren't likely - but if Linux becomes the
the platform of choice, we can try and make it so.

I haven't had time to check out what 2.5 is up to in respect to
the above issues - has anyone seen a good summary anywhere?

Michael

On Tue, 05 Nov 2002 05:38, Gary_Lerhaupt@Dell.com wrote:
> Are these physically separate USB storage devices made by the same
> manufacturer?  Or is this device more like a USB card reader and you are
> having problems differentiating between the cards that you put into the
> reader?  I have a feeling its the first case, which is unfortunate because
> with a bad ID like "1f00" for both, devlabel won't work for you.  Or, at
> least it would work for you if you only plugged in one at a time.
>
> If you do go with the one-at-a-time approach, then you could create a
> symlink name to be shared by both like /dev/neodio_storage and then go
> about automounting with /etc/fstab, etc.  However, this won't work for both
> at the same time (as you've seen).
>
> I'm interested in the usb-serial idea, though.   Where are these kept? 
> Even if they aren't implemented on many devices, I'd still like to add any
> possible identifier to make devlabel work in more scenarios.  You also
> mention a volume label, but with USB storage devices, this isn't likely.
> Well, at least not on my smart card reader.
> -Gary
>



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Ajay]

I've been thinking of a linux automount utility for
USB MSD compliant devices that works in conjunction
with hotplug. I basically read /proc/bus/usb/devices,
get the vid-pid-serial, read /proc/scsi/scsi to check
for SCSI devices, then read /proc/scsi/usb-storage-*/*
for the vid-pid-serial match (from the GUID). Now
since the serial match is vital for device
identification, this sort of shakes me up a bit.

> > The larger problem is that there are lots of USB
> storage devices
> > that don't have (or require) a serial number at
> all.  How are you
> > handling those?

AFAIK MSD Devices all need a serial number. Is that
right?

> Things get a little more confusing because, if a
> usb-device's serial
> changes when ever the device is unplugged and
> replugged, it will 
> march down the scsi bus.  For example, plug it in
> once and
> it appears as /dev/sda, unplug it and plug it in
> again and it will
> be /dev/sdb, then /dev/sdc, and so on. I suspect
> this is because 
> the usb-serial keeps changing.  

Again, AFAIK the serial can be changed only if the
Device firmware is flashed. Assuming a user will flash
it before plugging it in each time seems to be an
overkill.

> The only way I found
> to clear this 
> up is to unload the usb-storage module.

Also, the fact is that /dev/sda, etc. are only
'relative labels' - i.e. if you had plugged in a
device before the one you're using, _that_ would have
been /dev/sda and your device /dev/sdb, even if the
serial hasn't changed (this after unloading - loading
the usb-storage module). 

Thanks and regards
Ajay
--------------------------------
  I'm not
> sure if the kernel 
> can deal with this nicely - because, if it did, I
> think it would
> exhibit bad behaviour for devices that do have a
> constant serial.
> On the other hand, should a device hold onto
> /dev/sda a week after
> you unplugged it just because you haven't rebooted
> since - I guess
> the it should have a lease that times out.  
> 
> This is a messy business. I suspect the best that
> can be done 
> is to create a desktop folder where USB devices come
> and go.  
> Each device should named as meaningfully as possible
> and have 
> a tool-tip with as much info as can be retrieved
> about he 
> identity of the device (Manufacturer, Name, etc).
> But ultimately 
> the user must figure out which device is which by
> inspection.
> 
> Yeah - volume labels aren't likely - but if Linux
> becomes the
> the platform of choice, we can try and make it so.
> 
> I haven't had time to check out what 2.5 is up to in
> respect to
> the above issues - has anyone seen a good summary
> anywhere?
> 
> Michael
> 
> On Tue, 05 Nov 2002 05:38, Gary_Lerhaupt@Dell.com
> wrote:
> > Are these physically separate USB storage devices
> made by the same
> > manufacturer?  Or is this device more like a USB
> card reader and you are
> > having problems differentiating between the cards
> that you put into the
> > reader?  I have a feeling its the first case,
> which is unfortunate because
> > with a bad ID like "1f00" for both, devlabel won't
> work for you.  Or, at
> > least it would work for you if you only plugged in
> one at a time.
> >
> > If you do go with the one-at-a-time approach, then
> you could create a
> > symlink name to be shared by both like
> /dev/neodio_storage and then go
> > about automounting with /etc/fstab, etc.  However,
> this won't work for both
> > at the same time (as you've seen).
> >
> > I'm interested in the usb-serial idea, though.  
> Where are these kept? 
> > Even if they aren't implemented on many devices,
> I'd still like to add any
> > possible identifier to make devlabel work in more
> scenarios.  You also
> > mention a volume label, but with USB storage
> devices, this isn't likely.
> > Well, at least not on my smart card reader.
> > -Gary
> >
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact
> size!
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Linux-hotplug-devel mailing list 
> http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

On Wed, 06 Nov 2002 17:23, Ajay wrote:
> AFAIK MSD Devices all need a serial number. Is that
> right?
> ...

> ...
> Again, AFAIK the serial can be changed only if the
> Device firmware is flashed. Assuming a user will flash
> it before plugging it in each time seems to be an
> overkill.
> ...

No, the serial need not be something burned into the device.  
The device I have makes up a serial number on the fly.
Each time it is inserted it appends its position on the bus onto 
the end of the vendor and product id - so the serial is 
vendor-product-bus-location.  The next time I plug it
in the bus-location may differ, so the serial will differ.
This sums it up and adds a scary note on uniqeness:

On Tue, 08 Oct 2002 08:24, Matthew Dharm wrote:
| From: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
| Cc: linux-usb-users@lists.sourceforge.net
| Subject: Re: [Linux-usb-users] Auto mount/unmount: need explanation of serial numbers?
| On Mon, Oct 07, 2002 at 11:26:35AM -0700, Randy.Dunlap wrote:
| > On Mon, 7 Oct 2002, Matthew Dharm wrote:
| > 
| > | On Tue, Oct 08, 2002 at 01:11:01AM +1300, Michael Hamilton wrote:
| > | > 1. What part of the serial remains constant for the same device,
| > | >    if any?
| > |
| > | The whole thing should.  The compliance test that the USB-IF (including
| > | myself) are working on requires a constant serial number.
| > 
| > Matt, do you read that as part of any spec (requirement)?
| 
| Not exactly.  But the entire Mass Storage DWG was pretty supprised when I
| pointed out devices that had this broken behavior.
|
| The spec requires a 'unique' serial number, but does not specify what the
| domain for that uniqueness is.  The intent was to be unique over all
| devices with that VID:PID.  A few (a _very_ few) manufacturers chose to
| interpret this as unique for a given USB bus.
| 
| The changing serial number is because the bus address is incorporated into
| the serial number.
| 
| Of course, that means that it's possible to have two units on two different
| USB busses with the same bus address, and thus the same serial number.
|
| Matt
| 
| -- 
| Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net
| Maintainer, Linux USB Mass Storage Driver

Note, that although Matt states that only a few manufacturers have
done this, their chipsets may be turning up in many products.
There are several products that identify themselves as the same as
mine, but they're different kinds of devices: fixed usb-drives, card
readers, etc, all sold under different brands. 

On Wed, 06 Nov 2002 17:23, Ajay wrote:
> ...
> > The only way I found
> > to clear this
> > up is to unload the usb-storage module.
>
> Also, the fact is that /dev/sda, etc. are only
> 'relative labels' - i.e. if you had plugged in a
> device before the one you're using, _that_ would have
> been /dev/sda and your device /dev/sdb, even if the
> serial hasn't changed (this after unloading - loading
> the usb-storage module).
> ...

Yes, I understand this. The point I was trying to make was
that after I unplug the device, the /dev/sdX remains allocated 
forever. This is because the serial keeps changing.
And, because the serial keeps changing, I keep using more and more 
/dev/sdX entries.  And, as stated, the only way to clear them 
is to either reboot, or get to a point where usb-storage 
can be unloaded - that is, unplug all storage devices and 
then depmod -r usb-storage.  This is exacty what my current
solutions does - if it sees that there are no devices left
on the bus, it removes the module.

I was rather surprised by all this - it's a nifty device and
a great way to transport stuff to and from client sites, but
looking at how it fits into exiting ideas on mouting and 
partitioning was a real education (see 
http://users.actrix.co.nz/michael/usbmount.html for details)

Michael






-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: usb-mount (hotplug + desktop hooks)

[Gary_Lerhaupt]

I checked /proc/scsi/usb-storage-0 after plugging in my flashcard reader.
In my particular case, the device returned a Serial Number of "None" but did
return what appeared to be an interesting and unique GUID value.  Michael,
did you comments about the non-uniqueness of serial numbers also extend to
GUIDs?  

If not, I could immediately add USB GUIDs where applicable within devlabel
and then automounting would be simple.  Do your two USB storage devices
return different (yet consistent) GUID values?

Gary
devlabel: www.domsch.com/linux/devlabel

-----Original Message-----
From: Michael Hamilton [mailto:michael@actrix.gen.nz]
Sent: Wednesday, November 06, 2002 3:21 AM
To: a_ajay_sr@yahoo.com; Gary_Lerhaupt@exchange.dell.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: usb-mount (hotplug + desktop hooks)

No, the serial need not be something burned into the device.  
The device I have makes up a serial number on the fly.
Each time it is inserted it appends its position on the bus onto 
the end of the vendor and product id - so the serial is 
vendor-product-bus-location.  The next time I plug it
in the bus-location may differ, so the serial will differ.
This sums it up and adds a scary note on uniqeness:

Note, that although Matt states that only a few manufacturers have
done this, their chipsets may be turning up in many products.
There are several products that identify themselves as the same as
mine, but they're different kinds of devices: fixed usb-drives, card
readers, etc, all sold under different brands. 

On Wed, 06 Nov 2002 17:23, Ajay wrote:
> ...
> > The only way I found
> > to clear this
> > up is to unload the usb-storage module.
>
> Also, the fact is that /dev/sda, etc. are only
> 'relative labels' - i.e. if you had plugged in a
> device before the one you're using, _that_ would have
> been /dev/sda and your device /dev/sdb, even if the
> serial hasn't changed (this after unloading - loading
> the usb-storage module).
> ...

Yes, I understand this. The point I was trying to make was
that after I unplug the device, the /dev/sdX remains allocated 
forever. This is because the serial keeps changing.
And, because the serial keeps changing, I keep using more and more 
/dev/sdX entries.  And, as stated, the only way to clear them 
is to either reboot, or get to a point where usb-storage 
can be unloaded - that is, unplug all storage devices and 
then depmod -r usb-storage.  This is exacty what my current
solutions does - if it sees that there are no devices left
on the bus, it removes the module.

I was rather surprised by all this - it's a nifty device and
a great way to transport stuff to and from client sites, but
looking at how it fits into exiting ideas on mouting and 
partitioning was a real education (see 
http://users.actrix.co.nz/michael/usbmount.html for details)

Michael







-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

On Thu, 07 Nov 2002 04:53, Gary_Lerhaupt@Dell.com wrote:
> I checked /proc/scsi/usb-storage-0 after plugging in my flashcard reader.
> In my particular case, the device returned a Serial Number of "None" but
> did return what appeared to be an interesting and unique GUID value. 
> Michael, did you comments about the non-uniqueness of serial numbers also
> extend to GUIDs?
>
> If not, I could immediately add USB GUIDs where applicable within devlabel
> and then automounting would be simple.  Do your two USB storage devices
> return different (yet consistent) GUID values?
>
> Gary
> devlabel: www.domsch.com/linux/devlabel

I've already investigated this path.  Here's a summary...

I have two identical devices - lets call them A and B to save any
confusion.

1) Plug in device A:
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A002
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a002
         Attached: Yes
2) Unplug device A and plug it in again - note the serial and GUID
   are based on the same attributes - the vendor, product and bus 
   location.
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes
3) Plug in device B - note that it has the Serial and GUID we saw
   in step (1) above.
    viking2:~ % cat /proc/scsi/usb-storage-1/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A002
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a002
         Attached: Yes
4) Unplug device B and plug it in again- note it now has the same 
   serial and GUID as device A which is still plugged in.
    viking2:~ % cat /proc/scsi/usb-storage-1/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes

Not very nice. I guess the scsi device id could be added
to the serial or GUID to provide a unique identifier that
will last as long as the device is plugged in.

Michael



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: usb-mount (hotplug + desktop hooks)

[Gary_Lerhaupt]

Here is my solution.  Tell me what you think.  I'll add a --usb-guid option
to the devlabel add command.  When you try to do an add with --usb-guid, it
will first grab the SCSI ID and then grab the USB GUID.  It will then prompt
you to remove your USB device.  It will then prompt you to reattach your USB
device.  At this point it will confirm that the ID it received before is the
same ID it is getting now.  If both of these match, the add will proceed and
from then on it will reference the USB GUID to confirm consistency.

Unfortunately, this does little for you as your GUIDs are non-unique.  In
your scenario, the --usb-guid add would fail and it wouldn't allow you to
use the GUID as part of the ID of the device.  However, for things like my
card-reader and properly spec'd USB devices, this would alleviate dependence
on the 1F00 identifier.  Hey, maybe someone might even take the initiative
to compile a list of USB devices which have true consistent GUIDs.

What do you think?

-----Original Message-----
From: Michael Hamilton [mailto:michael@actrix.gen.nz]
Sent: Wednesday, November 06, 2002 11:03 PM
To: Gary_Lerhaupt@exchange.dell.com; a_ajay_sr@yahoo.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: usb-mount (hotplug + desktop hooks)


I've already investigated this path.  Here's a summary...

I have two identical devices - lets call them A and B to save any
confusion.

1) Plug in device A:
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A002
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a002
         Attached: Yes
2) Unplug device A and plug it in again - note the serial and GUID
   are based on the same attributes - the vendor, product and bus 
   location.
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes
3) Plug in device B - note that it has the Serial and GUID we saw
   in step (1) above.
    viking2:~ % cat /proc/scsi/usb-storage-1/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A002
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a002
         Attached: Yes
4) Unplug device B and plug it in again- note it now has the same 
   serial and GUID as device A which is still plugged in.
    viking2:~ % cat /proc/scsi/usb-storage-1/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes
    viking2:~ % cat /proc/scsi/usb-storage-0/0
       Host scsi0: usb-storage
           Vendor: Neodio Technologies Corp.
          Product: Neodio USB Storage Device
    Serial Number: 0AEC501000001A003
         Protocol: Transparent SCSI
        Transport: Bulk
             GUID: 0aec5010aec501000001a003
         Attached: Yes

Not very nice. I guess the scsi device id could be added
to the serial or GUID to provide a unique identifier that
will last as long as the device is plugged in.

Michael




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

Sounds OK for devices that have a unique GUID.  But I also suspect 
that if a GUID is unique, then scsi_unique_id will also be unique.  Does 
anyone know if this is true?

Returning to devices that cannot be uniquely identified. Perhaps devlabel 
could assign devices that don't have a unique ID to a series of 
predefined generically named symlinks.
  
Then 'devlabel restart' would first attempt to match and mount newly
inserted devices by matching ID's against known device IDs.  Failing a
match, if one or more generic symlinks are defined, it could assign the
device to the first one available.

The generic symlinks would only be used for devices that haven't
been defined by a 'devlabel add'.  Whether generics would be allowed 
could be determined by the use of a --generic 'devlabel add' option 
to create a number of them.  The creation of one or two generic 
symlinks would also allow devices that haven't been formally added 
to be used straight away.

Michael

On Fri, 08 Nov 2002 05:05, Gary_Lerhaupt@Dell.com wrote:
> Here is my solution.  Tell me what you think.  I'll add a --usb-guid option
> to the devlabel add command.  When you try to do an add with --usb-guid, it
> will first grab the SCSI ID and then grab the USB GUID.  It will then
> prompt you to remove your USB device.  It will then prompt you to reattach
> your USB device.  At this point it will confirm that the ID it received
> before is the same ID it is getting now.  If both of these match, the add
> will proceed and from then on it will reference the USB GUID to confirm
> consistency.
>
> Unfortunately, this does little for you as your GUIDs are non-unique.  In
> your scenario, the --usb-guid add would fail and it wouldn't allow you to
> use the GUID as part of the ID of the device.  However, for things like my
> card-reader and properly spec'd USB devices, this would alleviate
> dependence on the 1F00 identifier.  Hey, maybe someone might even take the
> initiative to compile a list of USB devices which have true consistent
> GUIDs.
>
> What do you think?
>
> -----Original Message-----
> From: Michael Hamilton [mailto:michael@actrix.gen.nz]
> Sent: Wednesday, November 06, 2002 11:03 PM
> To: Gary_Lerhaupt@exchange.dell.com; a_ajay_sr@yahoo.com
> Cc: Linux-hotplug-devel@lists.sourceforge.net
> Subject: Re: usb-mount (hotplug + desktop hooks)
>
>
> I've already investigated this path.  Here's a summary...
>
> I have two identical devices - lets call them A and B to save any
> confusion.
>
> 1) Plug in device A:
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A002
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a002
>          Attached: Yes
> 2) Unplug device A and plug it in again - note the serial and GUID
>    are based on the same attributes - the vendor, product and bus
>    location.
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
> 3) Plug in device B - note that it has the Serial and GUID we saw
>    in step (1) above.
>     viking2:~ % cat /proc/scsi/usb-storage-1/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A002
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a002
>          Attached: Yes
> 4) Unplug device B and plug it in again- note it now has the same
>    serial and GUID as device A which is still plugged in.
>     viking2:~ % cat /proc/scsi/usb-storage-1/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
>
> Not very nice. I guess the scsi device id could be added
> to the serial or GUID to provide a unique identifier that
> will last as long as the device is plugged in.
>
> Michael



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: usb-mount (hotplug + desktop hooks)

[Gary_Lerhaupt]

Well, my flashcard reader seems to have a good USB GUID that is consistent
in at least 2 different systems I've plugged it into.  However, it has a bad
scsi_unique_id of "1F00".  So, in its case, the --usb-guid would seem to
have worth.

As far as devices that aren't consistently unique, devlabel can already
handle this in the way that you would like (albeit, as long as you don't
plug in at the same time both USB storage devices made by the same vendor
but with bad scsi_unique_ids).  Just add a generic symlink for that type of
device like /dev/genericusb and regardless of which you plug-in, it will get
mapped to that symlink.  Perhaps, I could add a --force to allow the user to
connect 2 devices with the same ID at the same time.  I'd be worried that an
unknowing user might hurt himself with this, though.


-----Original Message-----
From: Michael Hamilton [mailto:michael@actrix.gen.nz]
Sent: Monday, November 11, 2002 2:12 AM
To: Gary_Lerhaupt@exchange.dell.com; a_ajay_sr@yahoo.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: usb-mount (hotplug + desktop hooks)


Sounds OK for devices that have a unique GUID.  But I also suspect 
that if a GUID is unique, then scsi_unique_id will also be unique.  Does 
anyone know if this is true?

Returning to devices that cannot be uniquely identified. Perhaps devlabel 
could assign devices that don't have a unique ID to a series of 
predefined generically named symlinks.
  
Then 'devlabel restart' would first attempt to match and mount newly
inserted devices by matching ID's against known device IDs.  Failing a
match, if one or more generic symlinks are defined, it could assign the
device to the first one available.

The generic symlinks would only be used for devices that haven't
been defined by a 'devlabel add'.  Whether generics would be allowed 
could be determined by the use of a --generic 'devlabel add' option 
to create a number of them.  The creation of one or two generic 
symlinks would also allow devices that haven't been formally added 
to be used straight away.

Michael

On Fri, 08 Nov 2002 05:05, Gary_Lerhaupt@Dell.com wrote:
> Here is my solution.  Tell me what you think.  I'll add a --usb-guid
option
> to the devlabel add command.  When you try to do an add with --usb-guid,
it
> will first grab the SCSI ID and then grab the USB GUID.  It will then
> prompt you to remove your USB device.  It will then prompt you to reattach
> your USB device.  At this point it will confirm that the ID it received
> before is the same ID it is getting now.  If both of these match, the add
> will proceed and from then on it will reference the USB GUID to confirm
> consistency.
>
> Unfortunately, this does little for you as your GUIDs are non-unique.  In
> your scenario, the --usb-guid add would fail and it wouldn't allow you to
> use the GUID as part of the ID of the device.  However, for things like my
> card-reader and properly spec'd USB devices, this would alleviate
> dependence on the 1F00 identifier.  Hey, maybe someone might even take the
> initiative to compile a list of USB devices which have true consistent
> GUIDs.
>
> What do you think?
>
> -----Original Message-----
> From: Michael Hamilton [mailto:michael@actrix.gen.nz]
> Sent: Wednesday, November 06, 2002 11:03 PM
> To: Gary_Lerhaupt@exchange.dell.com; a_ajay_sr@yahoo.com
> Cc: Linux-hotplug-devel@lists.sourceforge.net
> Subject: Re: usb-mount (hotplug + desktop hooks)
>
>
> I've already investigated this path.  Here's a summary...
>
> I have two identical devices - lets call them A and B to save any
> confusion.
>
> 1) Plug in device A:
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A002
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a002
>          Attached: Yes
> 2) Unplug device A and plug it in again - note the serial and GUID
>    are based on the same attributes - the vendor, product and bus
>    location.
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
> 3) Plug in device B - note that it has the Serial and GUID we saw
>    in step (1) above.
>     viking2:~ % cat /proc/scsi/usb-storage-1/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A002
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a002
>          Attached: Yes
> 4) Unplug device B and plug it in again- note it now has the same
>    serial and GUID as device A which is still plugged in.
>     viking2:~ % cat /proc/scsi/usb-storage-1/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
>     viking2:~ % cat /proc/scsi/usb-storage-0/0
>        Host scsi0: usb-storage
>            Vendor: Neodio Technologies Corp.
>           Product: Neodio USB Storage Device
>     Serial Number: 0AEC501000001A003
>          Protocol: Transparent SCSI
>         Transport: Bulk
>              GUID: 0aec5010aec501000001a003
>          Attached: Yes
>
> Not very nice. I guess the scsi device id could be added
> to the serial or GUID to provide a unique identifier that
> will last as long as the device is plugged in.
>
> Michael




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[Michael Hamilton]

While these busted devices are a bit of a pain, I don't like the 
idea of saying device-X can't be supported, or that more than 
one of device-X can't be supported. Especially when it operates 
quite well on other operating systems.

If we want these bad-devices to work, I don't think there is any
other alternative than to provide a range of generic mount points
in addition to well identified ones.

Providing unknown devices stay on the same generic mount-points 
for the duration of their presence, I don't think this approach 
will be much harder to understand than the similar situation that
arises when you have to sort through a pile of floppies.  
This is especially true if the desktop provides some kind of 
visual indication that devices have appeared and disappeared. 
For example, my scripted K-desktop solution immediately mounts 
the device and changes the associated icon 
( http://users.actrix.co.nz/michael/usbmount.html ).

On Tue, 12 Nov 2002 04:39, Gary_Lerhaupt@Dell.com wrote:
> Well, my flashcard reader seems to have a good USB GUID that is consistent
> in at least 2 different systems I've plugged it into.  However, it has a
> bad scsi_unique_id of "1F00".  So, in its case, the --usb-guid would seem
> to have worth.
>
> As far as devices that aren't consistently unique, devlabel can already
> handle this in the way that you would like (albeit, as long as you don't
> plug in at the same time both USB storage devices made by the same vendor
> but with bad scsi_unique_ids).  Just add a generic symlink for that type of
> device like /dev/genericusb and regardless of which you plug-in, it will
> get mapped to that symlink.  Perhaps, I could add a --force to allow the
> user to connect 2 devices with the same ID at the same time.  I'd be
> worried that an unknowing user might hurt himself with this, though.
>



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-mount (hotplug + desktop hooks)

[David Brownell]

Michael Hamilton wrote:
> 
> I tried two of the same device, devlabel's scsi_unique_id utility returns
> the same ID for both:
> 
> model: Neodio TNeodio/Leadtek W
> page83: No page83 information found.
> page80: 1f00

Yeah, there are a whole bunch more IDs that ought to be available
when making such decisions.  USB serial numbers for one, and also
"physical" IDs that don't change until you physically re-cable
the device or subsystem.  (And there are other labels ...)

2.5 has a kind of physical device ID available: the sysfs path
of the device. (It's less stable than it should be ... but that
can be improved.)  Bus or class level hotplug agents can use
/sys/$DEVPATH to see more info about the devices ... which I'll
suspect doesn't cover much of the data that'd be important to user
mode tools like devlabel or usb-mount.


I'm not sure what's up with "disk hotplug" (wasn't there a disk
"class" a while back?) or how it might relate to the /sys/block
stuff that I see lately.  Would someone working in that area have
any insights to share -- Pat, Greg?  :)

- Dave










-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel