> It is not feasible to recreate the UDI strings originally > generated by HAL, as HAL's internal structure is quite different than the > TDE HW backend. HAL uses many internal hacks/strings, which > contributed significantly to its unmaintainability and subsequent > deprecation; I do not want to repeat that mistake. Sure, I understand. Let me explain differently. I am not suggesting we recreate the UDI strings from the old mediamanagerrc, which are based upon how HAL works. I'm suggesting we grep those strings to create the new TDEHW strings by extracting the UUID related information. TDE probably can already extract the UUID when I device is connected. TDEHW should use that code. We then grep the old mediamanagerrc for that UUID and extract the related information. For example, suppose I insert my Kingston 8GB flash drive. For that one device my existing mediamnagerrc looks like this: ... [/org/freedesktop/Hal/devices/volume_uuid_4CAB_C505] atime=false flush=true mountpoint=/media/kingston_8gb quiet=false ro=false shortname=lower sync=false uid=true utf8=true ... [UserLabels] /org/freedesktop/Hal/devices/volume_uuid_4CAB_C505=Kingston 8GB USB ... When I insert that device, TDE/TDEHW discovers the UUID, and then TDEHW greps mediamanagerrc for that UUID. Then TDEHW, either through kreadconfig or its own code, extracts the information. Rather than a [UserLabels] string that looks like this: [UserLabels] /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host7/target7:0:0/7:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer 16GB USB Which changes when I insert the device into a different physical port, we create a strings like this: ... [volume_uuid_4CAB_C505] atime=false flush=true mountpoint=/media/kingston_8gb quiet=false ro=false shortname=lower sync=false uid=true utf8=true ... [UserLabels] volume_uuid_4CAB_C505=Kingston 8GB USB ... If whoever developed the code for mediamanagerrc under HAL had used this direct string approach, we would not need to create new strings under TDEHW. :-) My point is that the UUID is discoverable and dependable and can be used to create the new mediamanagerrc strings. Perhaps the first time TDE is started under TDEHW, TDEHW automatically updates mediamanagerrc rather than wait for those devices to be inserted. > The loss of old media manager settings will exist with any > replacement media backend unless great pains are taken to generate UDI > strings exactly the way HAL did; this issue is not unique to the TDEHWLib > backend. Yes, I understand that mediamanagerrc will be a tad cluttered until we get this all debugged. :-) Darrell