Do you know how the other desktops have access to the underlying block device in order to eject it?  Fundamentally this is a permissions issue; the other desktops you mention must use a different mechanism to which your user has had access granted.

I have KDE4 and Xfce installed and have access to 3.5.10 and 3.5.13 in virtual machines.

That suid is needed indicates something of a permissions issue, but where I don't know. That said, the 3.5.10 and 3.5.13 systems are HAL based. I'm guessing with the HAL systems that HAL notified everything of device changes and any related software needed to use those announcements accordingly.

My current system has udisks and udisks2 installed.

I noticed something related. Although the icon does not immediately disappear when selecting Safely Remove, as was the case in earlier versions of Trinity and KDE on HAL systems, the device is unmounted when selecting Safely Remove. Only when I physically remove the device does the icon disappear.

Similarly with my camera, powering off the device while connected causes the icon to disappear.

Possibly tdehwlib is removing the icons but not at the correct time.

I'll troubleshoot, but I don't know where to start.

It looks like the other desktops you mention use udisks2 to get around the permissions problem.  I have committed initial support for the udisks2 eject command in GIT hashes 43e1392 and 670690f.

Thanks. :) I'm kind of busy today. I will report late tonight or tomorrow on the results for this report.

Test results:

The icon does not disappear when selecting Safely Remove. The icon unmounts with Safely Remove but disappears after I remove the device.

On the desktop I lost my Trash icon and a $HOME/Desktop *.desktop file. The $HOME/Desktop file is a shortcut for the eject -T command for my DVD drive. Probably a coincidence because I can't get any of the other special device icons to appear on the desktop.

The following device icons appear on the desktop when enabled:

Unmount Floppy
Unmounted Hard Disk partition
Unmounted NFS Share

I forgot to add I need suid for /usr/bin/eject and none of the special device icons appear when using a fresh profile.

Do you have udisks2 installed on your system?

Yes, udisks2-1.98 (and udisks-1.0.4).

Start Trinity with a fresh profile to verify none of the special device icons appear. In the past all of them appeared on the desktop with a fresh profile.

I don't know how that is related to the ~/Desktop/*.desktop shortcut no longer appearing either. :)

(In reply to comment #9)
> Yes, udisks2-1.98 (and udisks-1.0.4).
> 
> Start Trinity with a fresh profile to verify none of the special device icons
> appear. In the past all of them appeared on the desktop with a fresh profile.
> 
> I don't know how that is related to the ~/Desktop/*.desktop shortcut no longer
> appearing either. :)

I am aware of the desktop icons issue and am working on it.  What I don't understand is why you still need suid on eject for device icon removal.

Did you recompile tdelibs with -DWITH_UPOWER2="ON" or an equivalent flag?

Yes, per the CMakeLists.txt, with the following:

-DWITH_UDISKS2=ON
-DWITH_UPOWER=ON

The build logs confirm:

//Enable UDISKS2 support
WITH_UDISKS2:BOOL=ON

//Enable UPOWER support
WITH_UPOWER:BOOL=ON

(In reply to comment #11)
> Yes, per the CMakeLists.txt, with the following:
> 
> -DWITH_UDISKS2=ON
> -DWITH_UPOWER=ON
> 
> The build logs confirm:
> 
> //Enable UDISKS2 support
> WITH_UDISKS2:BOOL=ON
> 
> //Enable UPOWER support
> WITH_UPOWER:BOOL=ON

Do you have permissions to eject the device via udisks2?  If the udisk2 eject fails, TDE will fail over to using the eject binary.  It might be possible for a user to have udisks eject permission and not udisks2 eject permission, I am not sure.

I don't know and don't yet know how to even check that relationship.

Your question prompted  me to look in my xsession-error log. I see the following:

eject: unable to eject, last error: Inappropriate ioctl for device
eject: device name is `/dev/sde1'
eject: expanded name is `/dev/sde1'
eject: `/dev/sde1' is not mounted
eject: `/dev/sde1' is not a mount point
eject: `/dev/sde1' is a multipartition device
eject: trying to eject `/dev/sde1' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/sde1' using SCSI commands
eject: SCSI eject failed
eject: trying to eject `/dev/sde1' using floppy eject command
eject: floppy eject command failed
eject: trying to eject `/dev/sde1' using tape offline command
eject: tape offline command failed

The messages seem to be from the eject command directly. Doesn't help know how eject interacts with udisks(2).

I can run eject -T from the command line, which opens and closes the DVD drive tray. When I try to run only the eject command with no parameters I see the same error messages:

eject: unable to eject, last error: Inappropriate ioctl for device

Running the following resulted in a similar message:

udisks --eject /dev/dvd

Eject failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Subsequent attempts to run the same command result in this:

Eject failed: Not Authorized

Last year I raised the same issue on the Slackware forum:

https://www.linuxquestions.org/questions/slackware-14/slackware-14-udev-eject-4175425297/

There are many hits on a web search.

Perhaps for the moment we restore the special device icons. I'll search some more about eject. I'm guessing tdehwlib is making the correct calls to udev/udisks2/eject, but something else is awry.

Tim,

I spent some time fiddling with this and finally ran across a patch (https://bugs.archlinux.org/task/25405?getfile=7391) for the eject command that solves the problem on my end. I will try to get the patch merged in Slackware, but that is my problem, not yours. :)

If we get the desktop icons restored I'll test and hopefull then we close this report.

(In reply to comment #15)
> Tim,
> 
> I spent some time fiddling with this and finally ran across a patch
> (https://bugs.archlinux.org/task/25405?getfile=7391) for the eject command that
> solves the problem on my end. I will try to get the patch merged in Slackware,
> but that is my problem, not yours. :)
> 
> If we get the desktop icons restored I'll test and hopefull then we close this
> report.

I am still working on the icons.  There are fundamental problems with the media:/ kioslave that have existed for a very long time; I am attempting to resolve them now.

Ok.

I wrote too soon about the eject problem. The patch does help at my end, but only for optical disks. After mounting an optical disk the Eject command from the popup menu works with the disk unmounting and the tray opening. The Safely Remove problem applies only to USB flash drives and will unmount the device but not remove/clear the icon. So we still have to cross the bridge later. (Sorry!)

(In reply to comment #17)
> Ok.
> 
> I wrote too soon about the eject problem. The patch does help at my end, but
> only for optical disks. After mounting an optical disk the Eject command from
> the popup menu works with the disk unmounting and the tray opening. The Safely
> Remove problem applies only to USB flash drives and will unmount the device but
> not remove/clear the icon. So we still have to cross the bridge later. (Sorry!)

The icons are not removed/cleared because the system has not ejected the drive.

To debug the udisks2 eject failure, try this:
1.) Install d-feet and launch it.
2.) File-->Connect to System Bus
3.) Click on org.freedesktop.UDisks2 in the left pane
4.) Find your removable block device in the list shown in the right pane and expand it
5.) Expand org.freedesktop.UDisks2.Drive
6.) Under Methods, double-click Eject
7.) In the pop-up dialog, type '{}' (without the quotes) and click Execute.

Is the device now ejected from the system?  If not, did an error message display in the lower pane of the pop-up dialog?

(In reply to comment #10)
> (In reply to comment #9)
> > Yes, udisks2-1.98 (and udisks-1.0.4).
> > 
> > Start Trinity with a fresh profile to verify none of the special device icons
> > appear. In the past all of them appeared on the desktop with a fresh profile.
> > 
> > I don't know how that is related to the ~/Desktop/*.desktop shortcut no longer
> > appearing either. :)
> 
> I am aware of the desktop icons issue and am working on it.  What I don't
> understand is why you still need suid on eject for device icon removal.
> 
> Did you recompile tdelibs with -DWITH_UPOWER2="ON" or an equivalent flag?

Desktop icons issue should now be fixed by commits to tdelibs and tdebase.  I still need debugging information from udisks2/d-feet as mentioned above. :-)

I have added preliminary (largely untested!) udisks eject support to tdelibs in GIT hash bfc7b3b.  Be sure to set both -DWITH_UDISKS="ON" and -DWITH_UDISKS2="ON", as TDE will try all known (enabled) methods in sequence until it either succeeds or exhausts all possibilities.  There are also some new debug messages in that commit that should give a better idea of what TDE is trying and when.

Ok. Don't spend much time on that for the next few days. I've updated with the previous patches and have all desktop icons again (yay!) and whatever other tdeio improvements. I'm freezing my local repo to support the final testing of bug reports 1446 and 1447. As I need to run a full build set this will take a day or two before I can test the latest UDISK patches.

There is a udev rule that might be causing some of the eject grief. When I get 1446 and 1447 out of the way I'll try to perform some testing as methodically as possible to pinpoint the root cause.

Related to comment 20, I see the following in my build logs for tdelibs:

CMake Warning:
  Manually-specified variables were not used by the project:

    WITH_UDISKS
    WITH_UDISKS2

Yet I also see this in the CMakeCache.txt:

//Enable UDISKS support
WITH_UDISKS:BOOL=ON

//Enable UDISKS2 support
WITH_UDISKS2:BOOL=ON

I'm confused!

(In reply to comment #23)
> Yet I also see this in the CMakeCache.txt:
> 
> //Enable UDISKS support
> WITH_UDISKS:BOOL=ON
> 
> //Enable UDISKS2 support
> WITH_UDISKS2:BOOL=ON
> 
> I'm confused!

Well, that was a fairly stupid mistake on my part!  Defining variables but not using them...

Fixed in GIT hash b426419.

I rebuilt tdebase to the latest GIT.

Optical disks eject fine and the desktop icon disappears after the tray opens.

USB flash drives now seem to behave correctly with the icon disappearing after selecting Safely Remove.

The icon disappears without the aforementioned patched version of the eject command or any modified udev rules.

Observations:

1. Sometimes the desktop icon disappeared immediately, sometimes only after about 30 seconds. The relationship seems to be the first instance requires about 30 seconds and thereafter in the same session disappears immediately. Initially this behavior seemed repeatable as I restarted Trinity and again the first instance required about 30 seconds for the icon to disappear. Thereafter the icon disappeared immediately. After a full reboot and flushing the ksycoca cache I could not repeat the behavior and the icon disappeared immediately on the first instance.

2. I have a floppy drive. I have the Unmounted Floppy and Mounted Floppy device icons enabled. The Unmounted icon appears on my desktop as expected when I start Trinity. Using the popup menu and selecting Mount did not work. Using Mount from the popup menu with a CD works as expected. The desktop icon never changes to Mounted floppy and my desktop response slowed to a crawl. Watching the xsession-errors log using tail did not reveal anything. That said, a full reboot seems to have resolved the behavior. I cannot repeat the problem.

3. Now for a really weird bug that needs attention. I inadvertently selected Refresh Desktop from the desktop popup menu. Thereafter the removable device icon popup menus all changed and none had the Safely Remove, Mount, Eject menu options. I'm attaching screen shots. I have seen this happen occasionally but never investigated. Now I see the connection and cause. Note, I saw the oddball KDiff3 menu option (second picture). I uninstalled that package, restarted Trinity, and again selected Refresh Desktop from the desktop popup menu. Same results, as seen in the third screen grab. We might as well fix this weirdo under this bug report.

After resolving the third problem we can close this report. The first two observations above likely are anomalies and we have them recorded for posterity in case somebody ever observes the same behavior.

Created attachment 1169 [details]
Screen shots of popup device icon popup menus

Attached are the aforementioned screen shots, 3 shots in one file.

(In reply to comment #26)
> Created attachment 1169 [details]
> Screen shots of popup device icon popup menus
> 
> Attached are the aforementioned screen shots, 3 shots in one file.

Fixed in GIT hash 96d0c54.

I'm going to close this report; please reopen if these issues recur.

Thanks for reporting!

All seems to be working. Thank you!

Note: I again saw the long delay to remove the desktop icon after selecting Safely Remove. The icons disappear immediately thereafter. I don't want to pursue that but just adding a note in case somebody else reports the same thing someday. :)

R14.0.0 is looking better each day. :)