Bug 133777 - hal thinks that disconnected floppy is present
hal thinks that disconnected floppy is present
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
: 135976 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-27 08:36 EDT by Leonid Kanter
Modified: 2013-03-05 22:41 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-18 21:36:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of hald --daemon=no --verbose=yes (4.32 KB, application/octet-stream)
2004-09-28 09:39 EDT, Leonid Kanter
no flags Details
lshal output (3.34 KB, application/octet-stream)
2004-09-28 09:41 EDT, Leonid Kanter
no flags Details
An output for lshal for a machine with a USB floppy (5.03 KB, text/plain)
2004-10-20 14:07 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Leonid Kanter 2004-09-27 08:36:34 EDT
Description of problem:

I have ultraportable laptop HP Omnibook 500 with floppy in docking
station. When updfstab was used, it did not detect floppy on undocked
laptop. Now hal thinks that floppy is present even whan laptop is
undocked, device is present in "Computer" window and it produces huge
delay if somebody tries to "open" it.  Floppy icon was not available
on this laptop in all previous versions of redhat linux (since fall
2001) and fedora core.

Version-Release number of selected component (if applicable):

0.2.98.cvs20040923-1

How reproducible:

always
Comment 1 David Zeuthen 2004-09-27 13:56:00 EDT
Hi,

please include the information mentioned here

 http://freedesktop.org/Software/HalTraces

Remember to shutdown the hal daemon by running 'service haldaemon
stop' as root.

Thanks,
David
Comment 2 Leonid Kanter 2004-09-28 09:39:58 EDT
Created attachment 104433 [details]
output of hald --daemon=no --verbose=yes
Comment 3 Leonid Kanter 2004-09-28 09:41:56 EDT
Created attachment 104434 [details]
lshal output
Comment 4 David Zeuthen 2004-09-28 12:35:53 EDT
Thanks for the traces. Apparently the kernel seems to believe there is
a floppy drive since /sys/devices/platform/floppy0 exists. I don't
have such a directory when my laptop has the DVD-ROM/LS-120 combo so
I'm a bit surprised. 

Do you have a /sys/block/fd0 directory? If you don't perhaps hal
should check this as well. 

Btw, the support for legacy floppy drives in sysfs isn't the best but
someone is working on it

 http://freedesktop.org/pipermail/hal/2004-September/001000.html

but this is not going to make FC3.
Comment 5 Bill Nottingham 2004-09-28 23:14:46 EDT
If you can open the device, you can do checks to see if it's actually
attached.
Comment 6 David Zeuthen 2004-09-29 03:49:37 EDT
comment 5: like open(2) returning ENODEV? Won't that spin up the
drive, btw?

Thanks,
David
Comment 7 Leonid Kanter 2004-09-29 07:54:32 EDT
[leon@omnibook fd0]$ LANG=C ls -l /sys/block/fd0
total 0
-r--r--r--  1 root root 4096 Sep 29  2004 dev
drwxr-xr-x  3 root root    0 Sep 29  2004 queue
-r--r--r--  1 root root 4096 Sep 29  2004 range
-r--r--r--  1 root root 4096 Sep 29  2004 removable
-r--r--r--  1 root root 4096 Sep 29  2004 size
-r--r--r--  1 root root 4096 Sep 29  2004 stat
Comment 8 Leonid Kanter 2004-09-29 08:02:39 EDT
This laptop's bios is able to emulate legacy floppy drive if usb
floppy is attached. It may be a reason. But updfstab somehow detects
that drive is absent.
Comment 9 David Zeuthen 2004-09-29 10:00:25 EDT
Leonid, thanks for the information. 

Notting: how does kudzu/updfstab test for this using /dev/fd0? I don't
have the hardware to test so I want to play it safe and make hal do
exactly the same thing.

Thanks,
David
Comment 10 Leonid Kanter 2004-09-29 12:29:09 EDT
I'm ready to do any tests with hal/updfstab on this laptop if it could
help.
Comment 11 Bill Nottingham 2004-09-29 16:04:46 EDT
open doesn't necessarily spin up the drive.

char path[32], name[32];
struct floppy_drive_struct ds;
int x, fd, rc;

for (x = 0; x < 3; x++) {
   snprintf(path, 31, "/dev/fd%d", x);
   fd = open(path, O_RDONLY|O_NONBLOCK);
   if (fd < 0)
       ... no drive here ...
       break;
   ioctl(fd, FDRESET, NULL);
   rc = ioctl(fd, FDGETDRVTYP, name);
   if (rc || !name || !strcmp(name, "(null)")) {
       .... no drive here ...
       close(fd);
       break;
   }
   rc = ioctl(fd, FDPOLLDRVSTAT, &ds);
   close(fd);
   if (rc)
       ... no drive here ...
       break;
   if (ds.track < 0)
       ... drive is not actually there ...
   else
       ... you have a drive
}

Comment 12 David Zeuthen 2004-10-15 09:13:39 EDT
Hi,

Sorry for the lag. This should be fixed in hal-0.4.0-2 which is now
available in Rawhide. This actually did happen with my new Thinkpad
T41 and I've also tested it on a desktop system.

Feel free to reopen this bug if it doesn't work for you.

thanks,
David
Comment 13 Leonid Kanter 2004-10-18 12:40:17 EDT
I've installed hal-0.4.0-3 - there is no entry for floppy in
/etc/fstab even when laptop is docked :( floppy works if I mount it
manually.
Comment 14 David Zeuthen 2004-10-18 13:26:25 EDT
*** Bug 135976 has been marked as a duplicate of this bug. ***
Comment 15 David Zeuthen 2004-10-18 14:59:22 EDT
OK, this is an easy fix. The default policy in
/usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi should include
these three lines

      <match key="storage.bus" string="platform">
        <merge key="storage.policy.should_mount" type="bool">true</merge>
      </match>

after line 33 (near the match on "sata", "ide" and so on). Will build
this into Rawhide today.
Comment 16 Michal Jaegermann 2004-10-18 15:37:56 EDT
Indded, a fix from comment #15 works-for-me.

There is one catch, though.  If I boot with both a USB floppy and
a regular floppy then the first is /media/floppy and the other
one is /media/floppy1.  If I will attach a USB floppy only after
a machine was booted then this is the other way around.

Where is this controlled?  It seems that "built-in" devices should
have precedence over those which may show up, or not, on some bus
or they will be "jumping" around depending on how things were booted.
An order in storage-policy.fdi does not seem to matter.
Comment 17 David Zeuthen 2004-10-18 15:45:50 EDT
> Indded, a fix from comment #15 works-for-me.

Nice, thanks for testing it.

> There is one catch, though.  If I boot with both a USB floppy and
> a regular floppy then the first is /media/floppy and the other
> one is /media/floppy1.  If I will attach a USB floppy only after
> a machine was booted then this is the other way around.
>
> Where is this controlled?  It seems that "built-in" devices should
> have precedence over those which may show up, or not, on some bus
> or they will be "jumping" around depending on how things were 
> booted.
> An order in storage-policy.fdi does not seem to matter.

The default policy doesn't guarantee stable mount point names for
optical drives or floppy drives, sorry. You should be able to match
your USB floppy drive with a .fdi file in 95userpolicy though and set
storage.policy.desired_mount_point_name to e.g. usbfloppy.

You will, however, get stable mount point names for partitioned media
when the label meets certain criteria (exists; being ASCII and not a
fully qualified path; label not already occupied).

Thanks,
David
Comment 18 Michal Jaegermann 2004-10-18 16:30:28 EDT
> You should be able to match
> your USB floppy drive with a .fdi file in 95userpolicy though and 
> set storage.policy.desired_mount_point_name to e.g. usbfloppy.

Ah, more "undocumented black magick".  Neither 'man fstab-sync' nor
http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html mention
anything about 'storage.policy' and even less about
'desired_mount_point_name'.   Grepping through /usr/share/hal/fdi
brings some examples, though.  But looking at these I believe
that if I will figure out what "match your USB floppy drive" may
mean in the context then I probably need something like

<merge key="storage.policy.desired_mount_point"
          type="string">usbfloppy</merge>

and nothing with "_name".  Definitely something for Aunt Tilly. :-)
Comment 19 David Zeuthen 2004-10-18 17:15:07 EDT
> Ah, more "undocumented black magick".
>  Neither 'man fstab-sync' nor
> http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html mention
> anything about 'storage.policy' and even less about
> 'desired_mount_point_name'.   Grepping through /usr/share/hal/fdi
> brings some examples, though.

Get the facts here:

 http://freedesktop.org/~david/hal-spec/hal-spec.html

and I think I also gave you that link of fedora-test-list. Also try
out hal-device-manager to get a picture of what is happening.

> But looking at these I believe
> that if I will figure out what "match your USB floppy drive" may
> mean in the context then I probably need something like
> 
> <merge key="storage.policy.desired_mount_point"
>           type="string">usbfloppy</merge>
>

You want to match on storage.bus and storage.drive_type before merging
that property.

> and nothing with "_name".

Whatever - I was citing from memory.

> Definitely something for Aunt Tilly. :-)

Perhaps Aunt Tilly doesn't care about having stable mount point names.
She simply clicks the icon named "External Floppy Drive" in
computer:/// in Nautilus.

David
Comment 20 Michal Jaegermann 2004-10-18 18:50:12 EDT
> Get the facts here:

>  http://freedesktop.org/~david/hal-spec/hal-spec.html

'man fstab-sync' explicitely refers a reader to
http://freedesktop.org/Software/hal
and the only spec link under this url sends to
http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html

> and I think I also gave you that link of fedora-test-list

Possibly.  Expecting that a system user will be trawling through
archives of fedora-test-list for an unexpected morsel of information
is hardly realistic or constructive.

> Perhaps Aunt Tilly doesn't care about having stable mount point
> names.

Perhaps.  If her nephew wrote her a script which does something
important to her, and for which she got a new launcher or an icon
to click upon and/or this is running from cron, she might care if
that script happens to use that name.  Contrary to what you may
imagine this is a pretty frequent situation.  Substitute "a small
business outfit with no real expert around" for "Aunt Tilly".
Not everybody "only clicks".

If you will say that I can write that script in some other way
then indeed _I_ can.  But if it there for many years then it is
not likely the the code will expect a floppy to move around.

In case if you wonder if somebody writes scripts which depends
on floppies then, regardless how strange that may sound, I actually
did and it was a "business operation critical".  No kidding.
Comment 21 David Zeuthen 2004-10-18 21:36:11 EDT
This should be fixed in hal-0.4.0-4.
Comment 22 Jef Spaleta 2004-10-18 23:46:39 EDT
Re: comments #20 - #16

I think having the named mountpoints explicitly seperated by bus in
default settings for floppies makes sense to me and is consistent i
think with the fallback storage policy for "disks." For whatever
reasons the fallback storage policy for disks is, the same reasons
could be applied to other storage devices. usbfloppy for usb floppy
devices seems like a reasonable default to me, similar to idedisk and
usbdisk. I'd also have to wonder about if its worth seperating
cdrecorders explicitly by bus as well.  

I'm not so sure AT cares either way, about what the specific
mountpoints are.  But there are certainly going to be lots of niche
automation cases that will care about somewhat predictable mountpoints
at boot for non-hotplugged devices. Hotpluggable buses like usb and
firewire are a real pain in the ass in terms of predictability. I
certaintly don't expect to the numerical ordering of usb devices to be
predictable at boot. But I would much prefer having the devices on
more "static" buses be isolated from the lottery inherent in usb
device ordering.  So what's the downside to seperating out floppy
mountpoints by bus type?

But this brings up a thought i had. Is there room here for a tool that
can "freeze out" a specific fstab entry and mountpoint for a unique
device and create a policy definition without the user having to build
the xml by hand? Say i want my usbstick to have a specific fstab entry
associated with a specific mountpoint name. Would it be possible to
build a tool that i could run once i had my fstab entry configured and
my mountpoint created that could turn my configured settings into a
hal policy definition for that device?

-jef
Comment 23 David Zeuthen 2004-10-19 00:05:05 EDT
Using stuff like /media/usbfloppy and /media/floppy would violate
FHS2.3, sorry (though I personally would appreciate it). Perhaps it
would also be good to have some more examples in
/usr/share/doc/hal-@VERSION@/conf?

Btw, if you want stable mount point names for partitioned media you
can just label the filesystems and ensure that the label is a) ASCII
and b) doesn't specify an absolute path. Then fstab-sync will take the
label and massage it by replacing non-digits and non-letters with _.
For example, on my Powerbook running Fedora I have
/media/Mac_OS_X_Disk which is added as an HFS+ partition.

This, for me (but I wrote it so my judgement is probably impaired)
should be clear from
/usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi I'd hope?
Perhaps that file should start with a short textual presentation of
the policy it contains?

Cheers,
David
Comment 24 victor lorenz 2004-10-19 09:16:56 EDT
While there is now an entry in fstab for the floppy (with pamconsole
parameter??) still shows " no fstab entry" when one tries to mount
floppy. Still nothing for the zip drive in fstab. Using kernel 624 and
latest hal and udev.
Comment 25 David Zeuthen 2004-10-19 09:53:45 EDT
> While there is now an entry in fstab for the floppy (with pamconsole
> parameter??) still shows " no fstab entry" when one tries to mount
> floppy.

What exactly does this mean? What does the /etc/fstab look like?

Thanks,
David
Comment 26 victor lorenz 2004-10-19 10:34:31 EDT
Tried again; floppy now accessible in both KDE and Gnome (KDE was
problem) 

fstab:
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/                 /                       ext3    defaults     
  1 1
LABEL=/boot             /boot                   ext3    defaults     
  1 2
none                    /dev/pts                devpts  gid=5,mode=620
 0 0
none                    /dev/shm                tmpfs   defaults     
  0 0
none                    /proc                   proc    defaults     
  0 0
none                    /sys                    sysfs   defaults     
  0 0
/dev/hda5               swap                    swap    defaults     
  0 0
/dev/hda1               /mnt/windows            vfat    auto,umask=0 0 0

/dev/hdc                /media/cdrecorder       iso9660,udf
pamconsole,ro,exec,noauto,managed 0 0
/dev/fd0                /media/floppy           auto   
pamconsole,exec,noauto,managed 0 0
Comment 27 Michal Jaegermann 2004-10-19 23:53:37 EDT
In comment #17 David Zeuthen wrote:

> You should be able to match
> your USB floppy drive with a .fdi file in 95userpolicy though and set
> storage.policy.desired_mount_point_name to e.g. usbfloppy.

so I decided to give that a try and added a file in 95userpolicy
directory with the following contents:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> 

<deviceinfo version="0.2">
  <device>
    <match key="info.product" string="USB Floppy Drive">
       <merge key="storage.policy.desired_mount_point"
                           type="string">usbfloppy</merge>
    </match>
  </device>
</deviceinfo>

If I guess (the only option) things correctly this should "match". 
'hal-device-manager' indeed shows up for that USB floppy
a new key "storage.policy.desired_mount_point" with a value
"usbfloppy" so it seems that I "matched".  But after /etc/fstab
was redone by fstab-sync a mount point for this device is
once again either /media/floppy or /media/floppy1, depending
on circumstances.  Do I miss something here or this is another
bug?

BTW, if I will load above into emacs trying to edit it then emacs
goes into SGML-mode, like requested, but for this to be useful one
needs to load DTD.  There is /usr/share/hal/fdi/fdi.dtd but trying
to validate that I get:

cd /usr/share/hal/fdi/
nsgmls -s  fdi.dtd
nsgmls:fdi.dtd:5:2:E: "ELEMENT" declaration not allowed in prolog
nsgmls:fdi.dtd:6:2:E: "ATTLIST" declaration not allowed in prolog
nsgmls:fdi.dtd:10:2:E: "ELEMENT" declaration not allowed in prolog
nsgmls:fdi.dtd:12:2:E: "ELEMENT" declaration not allowed in prolog
nsgmls:fdi.dtd:13:2:E: "ATTLIST" declaration not allowed in prolog
nsgmls:fdi.dtd:20:2:E: "ELEMENT" declaration not allowed in prolog
nsgmls:fdi.dtd:21:2:E: "ATTLIST" declaration not allowed in prolog
nsgmls:fdi.dtd:24:2:E: end of document in prolog

Once again it looks that I miss something here.
Comment 28 David Zeuthen 2004-10-20 10:31:36 EDT
OK, matching on info.product is not the best thing since it varies
across different hardware and is generic; matching on storage.model,
which assumes the same value but only for storage devices, would be
better. Also, my Lacie USB Floppy Drive has storage.model set to
"USB-FDU". But you can do this so it works on all USB floppy drives by
matching on the storage.bus and storage.drive_type properties; does
this .fdi file work you you?

 <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
 <!-- Use 'usbfloppy' for USB floppy drives  -->
 <deviceinfo version="0.2">
   <device>
     <match key="storage.bus" string="usb">
       <match key="storage.drive_type" string="floppy">
         <merge key="storage.policy.desired_mount_point"
                type="string">usbfloppy</merge>
       </match>
     </match>
   </device>
 </deviceinfo>

It works for me; I'm getting this entry in /etc/fstab

 /dev/sda                /media/usbfloppy        auto   
pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

Cheers,
David
Comment 29 Michal Jaegermann 2004-10-20 12:04:35 EDT
> does this .fdi file work you you?

The one from a comment #28 indeed does work for me. Thanks!

I understand that in general matching on info.product
may be not the best way to do that.  Still in that particular case
I am experimenting with this is a unique key so one would think
that this we would be good enough.  This clearly is not the case.
Even copying into my previous version

  <match key="storage.drive_type" string="floppy"> ... </match>

does not help.  Obviously something else is going on here which
is not easy to fathom.

In playing with the above make sure that there are no /media/floppy*
entries before fstab updates or you may end up with something like 
/media/floppy2 for your regular floppy.

A visible difference between the cases in 'hal-device-manager'
display is that "storage.policy.desired_mount_point" moved down
from a "USB Floppy Drive" level to that of "USB-FDU".  It appears
that this matters but why?

Doesn't everybody finds a name 'hal-device-manager' exceedingly
funny?  It "manages" in the same sense as 'cat' manages a content
of a file.

And one more thing.  Can we have examples, likely the best place
in 'man fstab-sync', of a "manual" usage of that program?  It is
very far from clear what in that context "UDI" can be and and
expansion to "Unique Device Identifier" still does not explain
that much.  It is not unthinkable that one would want to invoke
'fstab-sync' in some shell scripts, for example.
Comment 30 David Zeuthen 2004-10-20 12:27:51 EDT
> > does this .fdi file work you you?
> 
> The one from a comment #28 indeed does work for me. Thanks!

Cool.

> I understand that in general matching on info.product
> may be not the best way to do that.  Still in that particular case
> I am experimenting with this is a unique key so one would think
> that this we would be good enough.

Are you sure about that? try attaching the output of lshal with your
USB floppy drive plugged in and we'll see.

> This clearly is not the case.
> Even copying into my previous version
> 
>   <match key="storage.drive_type" string="floppy"> ... </match>
> 
> does not help.  Obviously something else is going on here which
> is not easy to fathom.

Let's see what lshal says.

> In playing with the above make sure that there are no /media/floppy*
> entries before fstab updates or you may end up with something like 
> /media/floppy2 for your regular floppy.

fstab-sync --clean cleans all entries in /etc/fstab if they are not
mounted. This is done when the hal daemon starts (as stated in the man
page IIRC). Since the option 'noauto' is added practically all entries
ever generated by fstab-sync is deleted on bootup since they are not
mounted. Part of the bootstrap process for the hal daemon adds new
entries.

> A visible difference between the cases in 'hal-device-manager'
> display is that "storage.policy.desired_mount_point" moved down
> from a "USB Floppy Drive" level to that of "USB-FDU".  It appears
> that this matters but why?

Need lshal output.

> Doesn't everybody finds a name 'hal-device-manager' exceedingly
> funny?  It "manages" in the same sense as 'cat' manages a content
> of a file.

Certainly; that's why this (crappy; I know, cause I wrote it in like
two days :-) program is not installed by default and it doesn't show
up in any GUI. It is more or less unsupported. For FC4 we have plans
to write a real kick-ass gnome-device-manager program that indeed lets
you manage, configure and troubleshoot your hardware and even,
perhaps, provide those nasty bubbles you know from other operating
systems :-). But that is blue sky right.

Nonetheless, h-d-m is very useful for learning about the vast amount
of information that HAL exports as properties. Which is nice. And that
is why the hal-gnome package still exists.

> And one more thing.  Can we have examples, likely the best place
> in 'man fstab-sync', of a "manual" usage of that program?  It is
> very far from clear what in that context "UDI" can be and and
> expansion to "Unique Device Identifier" still does not explain
> that much.  

This is in the hal spec which will be included in hal-devel in due
time (hopefully for FC3; once I figure out how to build it in Beehive
:-). At that time the manual page for fstab-sync will point to that
package and fs location of the spec.

One thing to keep in mind is that fstab-sync is just a simple policy
agent for modifying the /etc/fstab file; it is not totally unlikely
this may go away one in favour of a policy mount wrapper that just
takes a HAL UDI (then checks if it's ok to mount; creates the mount
point; then mounts; all in one go). One argument for such a wrapper is
that it is invoked in the users desktop session; hence we can popup
dialogs for stuff like passworded media etc. This is also blue sky.. 

Unfortunately too much software depends on the /etc/fstab file and we
would need to patch that software to ask HAL about the devices.
Examples of this includes the GNOME and KDE desktops, Mozilla,
OpenOffice.org, Java etc. etc. And that is a lot of work.

> It is not unthinkable that one would want to invoke
> 'fstab-sync' in some shell scripts, for example.

I can't see at this point why this should ever ever be needed but,
hey, it's your computer and you can write any shell script you want :-)

Cheers,
David
Comment 31 Michal Jaegermann 2004-10-20 14:07:17 EDT
Created attachment 105534 [details]
An output for lshal for a machine with a USB floppy

> try attaching the output of lshal with your USB floppy drive plugged in
> and we'll see.

OK, if you want to see the whole thing. :-)

'lsusb' shows at this moment
Bus 005 Device 001: ID 0000:0000  
Bus 004 Device 002: ID 054c:002c Sony Corp. 
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 001: ID 0000:0000  
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000  

with this "Sony Corp." beeing that "USB Floppy Drive" and the rest are hubs.
So the machine is not crawling with USB devices after all.  OTOH 'lshal'
indeed reports two entries, with UDIs
'/org/freedesktop/Hal/devices/usb_usb_device_54c_2c_501_-1_noserial_0'
'/org/freedesktop/Hal/devices/usb_device_54c_2c_501_-1_noserial'
where a string "USB Floppy Drive" occures.  It is still clear that both
refer to the same physical device and "info.product = 'USB Floppy Drive'"
is unique to the second one.

Why one of these is preferable to another is still to me a mystery.

> > It is not unthinkable that one would want to invoke
> > 'fstab-sync' in some shell scripts, for example.

> I can't see at this point why this should ever ever be ...

Me too at this moment but my crystal ball was sent for warranty repairs.
Maybe I would wish for some device to temporary "disappear" for some reasons?
Comment 32 David Zeuthen 2004-10-20 14:39:38 EDT
> It is still clear that both refer to the same physical device and
> "info.product = 'USB Floppy Drive'" is unique to the second one.
>
> Why one of these is preferable to another is still to me a mystery.

Go read the USB standard; basically it comes down to that you may have
N>=1 interfaces for each USB device. It's gets fun when you consider
that a USB device also have configurations which may add/remove/change
interfaces depenedent on e.g. when it's buspowered or powered by
itself. Add to this that the metal (e.g. the enclosure we humans see
as the device) might expose several USB devices and perhaps even a USB
hub and it's more funny. Such is life.

Basically you are assuming that info.product is unique when it's not;
where do you read that it should? The only thing the hal spec says is
that it's something that can be used to represent the name of the
device object. 

Perhaps you are confused about all the various devices exported by
HAL, I know I am at some time even though I wrote this. The only
really 'interesting' devices are those with ''Functional Properties''
like storage.* volume.* on them; the rest is just glue. Just glue.

For instance, a hal device object representing a SCSI Host emulation
software object deep in the kernel is just not interesting. But it is
needed to glue the interesting parts together: the USB device (and USB
Mass Storage Interface on that device) and the block device
abstractions spawned from that one.

Anyway, FWIW, info.product is a property made up in HAL such
bus-dependent guesses on where from the metal it comes from. So for
PCI devices it comes from the PCI product id that we translate via
/usr/share/hwdata/pci.ids, for USB devices from the USB vendor ID and
so on. This abstraction is useful, e.g. we reduce the
'switch-on-bus-and-take-either-usb.product-or-pci.product. And this is
useful as we may introduce a new bus type at any point in time and
then we don't want to recompile said programs that does their own switch.

I hope this clarifies.
Comment 33 Michal Jaegermann 2004-10-20 15:09:08 EDT
> Basically you are assuming that info.product is unique when it's not;
> where do you read that it should?

I only said that info.product is unique __on that particular
installation__ and, so far, it does not "should"; it simply is.
It appears that this is not good enough contrary to what one may
naively expect.  That is why I originally had some doubts what
"match" may mean and it turns out that I was right in that.

It is only natural that various things become "obvious" after
you were developing them for a longer while; for the rest of
us this still looks like a guessing game.
Comment 34 Michal Jaegermann 2004-10-21 13:51:27 EDT
> > It is not unthinkable that one would want to invoke
> > 'fstab-sync' in some shell scripts, for example.

> I can't see at this point why this should ever ever be needed

It came to my mind at least one natural scenario when you may want to
use such script.  Undoubtedly there will be more.

Assume that we have a machine with multiple CD (or DVD) readers.
Not so frequent in a desktop situation but very far from unheard
of for data servers.  It is quite likely that you want to keep
consistent mount points for these devices and, for whatever reasons,
you may not want to take out that farm from a 'hal' management.
You may have, oh well, say a dozen of these.

It seems that to ensure a consistent naming now and in the future,
with all possible software changes which may affect a scan order,
etc., etc., you may want to 'fstab-sync -r ...' all these devices on
a startup and 'fstab-sync --add=$udi' them back following a fixed UDI
list.

If one could pass to 'fstab-sync' also as an argument a value for
'storage.policy.desired_mount_point', instead of editing files in
/usr/share/hal/fdi/95userpolicy, that would be nice bonus.  Think
about some of these devices breaking which may require temporary or
permanent rearrangements.  Yes, yes, we know that "desired" does
not mean "assured".

Note You need to log in before you can comment on or make changes to this bug.