On mar, 2009-04-28 at 08:00 -0600, Scott Barker wrote: > > Attached are two logs from lshal -m, one with thunar run as a foreground > process, the other with it running as a daemon. There is no other output > to any other logs related to this problem.
When running as a foreground process, you didn't quit between the first connect and the second one, did you? It looks to me like a hal problem (device correctly appears in the kernel logs, but not in hal). > > The only other thing I have noticed during testing is that every time > the device is removed and re-inserted, a new [scsi_eh_X] process appears > in the process list, where 'X' is incremented each time. Similarly, in > the kernel output (dmesg), when the device is scanned, it gets a > different scsi device ID (as in 'sd XX:0:0:0: [sdb] ...', where XX > increments each time). > > Perhaps thunar is somehow caching hardware state when running as a > daemon, and the change in scsi ID is not being picked up? I don't think thunar caches anything. It relies on hal events to notice that a removable device appeared. What's weird is that thunar influences hal, which seems really very weird. I'm a bit stuck here, to be honest. -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org