usb-mount (hotplug + desktop hooks)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Am Samstag, 26. Oktober 2002 01:46 schrieb David Brownell:
Quoted 8 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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
Quoted 14 lines · On Tue, 29 Oct 2002 10:52, [email protected] 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/fstabis because of the changing/dev/sdnames. 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/devlabelrestart
[ -x usb-mount ] && usb-mount
...
Quoted 6 lines
Michael, if you're looking for devlabel, it can be found at:
http://domsch.com/linux/devlabelGary 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Saturday, November 02, 2002 5:33 PM
To: [email protected]; [email protected]
Cc: [email protected]
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
Quoted 1 line · On Tue, 29 Oct 2002 10:52, [email protected] wrote:
I am especially intrigued by the idea of desktop hooks for when a usb
event
Quoted 13 lines
(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/fstabis because of the changing/dev/sdnames. 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/devlabelrestart
[ -x usb-mount ] && usb-mount
...
Quoted 6 lines
Michael, if you're looking for devlabel, it can be found at:
http://domsch.com/linux/devlabelGary 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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.
Quoted 23 lines
From: "Randy.Dunlap" <[email protected]>
X-X-Sender: <[email protected]>
To: Michael Hamilton <[email protected]>
Cc: <[email protected]>
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.
Quoted 8 lines
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?
Signature · 1 line
~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
Quoted 12 lines · On Tue, 05 Nov 2002 05:38, [email protected] 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_storageand then go about automounting with/etc/fstab, etc. However, this won't work for both at the same time (as you've seen).
Quoted 7 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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.
Quoted 5 lines
Quoted 1 line
The larger problem is that there are lots of USB
storage devices
Quoted 1 line
that don't have (or require) a serial number at
all. How are you
Quoted 1 line
handling those?
AFAIK MSD Devices all need a serial number. Is that right?
Quoted 11 lines
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.
Quoted 3 lines
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
Quoted 58 lines
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/sdaa 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
Quoted 1 line · On Tue, 05 Nov 2002 05:38, [email protected] wrote:
Are these physically separate USB storage devices
made by the same
Quoted 1 line
manufacturer? Or is this device more like a USB
card reader and you are
Quoted 1 line
having problems differentiating between the cards
that you put into the
Quoted 1 line
reader? I have a feeling its the first case,
which is unfortunate because
Quoted 1 line
with a bad ID like "1f00" for both, devlabel won't
work for you. Or, at
Quoted 1 line
least it would work for you if you only plugged in
one at a time.
Quoted 2 lines
If you do go with the one-at-a-time approach, then
you could create a
Quoted 1 line
symlink name to be shared by both like
/dev/neodio_storageand then goQuoted 1 line
about automounting with
/etc/fstab, etc. However,this won't work for both
Quoted 2 lines
at the same time (as you've seen).
Quoted 15 lines
Quoted 1 line
I'm interested in the usb-serial idea, though.
Where are these kept?
Quoted 1 line
Even if they aren't implemented on many devices,
I'd still like to add any
Quoted 1 line
possible identifier to make devlabel work in more
scenarios. You also
Quoted 1 line
mention a volume label, but with USB storage
devices, this isn't likely.
Quoted 3 lines
Well, at least not on my smart card reader.
-Gary
-------------------------------------------------------
Quoted 4 lines
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
Quoted 5 lines
_______________________________________________
Linux-hotplug-devel mailing list
http://linux-hotplug.sourceforge.net
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Ajay
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 <[email protected]> | Cc: [email protected] | 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: [email protected] | 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.
Quoted 5 lines · Ajay
...
Quoted 3 lines
The only way I found
to clear this
up is to unload the usb-storage module.
Quoted 7 lines
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/sdaand 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Wednesday, November 06, 2002 3:21 AM
To: [email protected]; [email protected]
Cc: [email protected]
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.
Quoted 5 lines · Ajay
...
Quoted 3 lines
The only way I found
to clear this
up is to unload the usb-storage module.
Quoted 7 lines
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/sdaand 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · On Thu, 07 Nov 2002 04:53, [email protected] wrote:
I checked
/proc/scsi/usb-storage-0after 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?
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Wednesday, November 06, 2002 11:03 PM
To: [email protected]; [email protected]
Cc: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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
Quoted 86 lines · On Fri, 08 Nov 2002 05:05, [email protected] 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:[email protected]]
Sent: Wednesday, November 06, 2002 11:03 PM
To: [email protected]; [email protected]
Cc: [email protected]
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
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Monday, November 11, 2002 2:12 AM
To: [email protected]; [email protected]
Cc: [email protected]
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
Quoted 1 line · On Fri, 08 Nov 2002 05:05, [email protected] wrote:
Here is my solution. Tell me what you think. I'll add a --usb-guid
option
Quoted 1 line
to the devlabel add command. When you try to do an add with --usb-guid,
it
Quoted 84 lines
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:[email protected]]
Sent: Wednesday, November 06, 2002 11:03 PM
To: [email protected]; [email protected]
Cc: [email protected]
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
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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 ).
Quoted 5 lines · On Tue, 12 Nov 2002 04:39, [email protected] 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_idof "1F00". So, in its case, the --usb-guid would seem to have worth.
Quoted 9 lines
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/genericusband 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Michael Hamilton
I tried two of the same device, devlabel's
scsi_unique_idutility 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel