> Thank you for the information.  Can you please send in
> the screenshots I asked for earlier?  Those screenhots would help me
> debug the label problems.

Which screenshots are those? I must have missed that email. If you mean pictures of each device icon, I'll post some soon.

> Regarding the slow detection of devices, I do not see that
> here, and when combined with the eject failure it sounds like udev is just
> plain buggy on your system.  For instance, eject works fine here
> (eject is not a TDE program).  To determine if udev really is this slow on
> your system, please run this in a terminal:
> udevadm monitor

Ah, that partially reveals what is happening. :-) udev is detecting devices immediately but the icons do not appear for a long time.

I have been testing with my primary traveling 16 GB USB flash drive. When I tested with a 8 GB USB flash drive, the icon appeared within two seconds.

I don't know what is happening here. There is a huge volume of udev spew when I insert the 16 GB USB flash drive. The icon does not appear until the spew ends.

Similar spew happens with the 8 GB drive, but much less in volume, and the icon appears much sooner.

The 16 GB device contains thousands of files, such as music files, photos, videos, portable apps, etc. Yet the 8 GB device contains many files too (hundreds/thousands), although not as many as the 16 GB device.

The 16 GB device is a Cruzer and the 8 GB device is a Kingston.

I tried a 8 GB Cruzer and the same slow icon appearance. I tried a 1 GB Buffalo and the icon appeared quickly.

All of the flash drives have many files on them.

At this time the only commonality I notice is Cruzer manufacturing. Possibly with the newer udev package there are some rule changes causing this weird effect. I don't know. I have not tested with a different desktop environment.

I have to reboot to run the same same tests on a HAL system. I'll add to the report later.

> Please remember that there is NO good, stable replacement
> for HAL anywhere in the Linux ecosystem.  TDE can only work with the
> information given to it by several upstream projects such as udev, and if those
> projects don't function correctly on your system you may need to revert to
> using HAL until they fix their bugs.

Yes, I understand that. I don't know why HAL was abandoned when HAL was working well. Yet know that TDEHW is coming along nicely. Sure, bugs exist, but we're making progress. :-)

Darrell