Bug 1666

You are correct; this is a user permissions issue.  However, I like your suggestion of a tdesu popup!

Hi,

I tried to click on other partitions while running Gnome Nautilus file manager on TDE and I can access to the other partitions without problems.

When TDE says that they are not removable devices, it is true, but, something should be done to make sure that there is a way to access other partitions.

Thanks!
-Alexandre

Hi,

I raised the priority number, because it is something of great importance, and a regression too.

Thanks!
-Alexandre Couture

On my usb drive I have two partitions - first fat, second ext3. I tested with current nightly-builds on Debian Wheezy. After connect to usb was opened two dialogs asking to mount partition => after confirmation has successfully mounted both partitions.

Hi,

Just to make sure that we are talking of the same thing:
I am talking about mounting other partitions on the same hard disk drive, which is not a removable drive.

On that computer, I have many partitions:
-Windows 7 (came with the computer...)
-Data partition for Windows 7
-Mageia 3
-Ubuntu 13.04
-Swap

These are the other partitions that I can't access in TDE R14.

I will release in a few week a fully updated version of my livecd. I am not sure yet if I will do a release with the first release of R14, because of many little thing that I am not sure yet about. And 3.5.13.2 is rock solid :)

-Alexandre

(Odpověď na komentář #5)
> Hi,
> 
> Just to make sure that we are talking of the same thing:
> I am talking about mounting other partitions on the same hard disk drive, which
> is not a removable drive.
> 
> -Alexandre

Yes, we had a different situation. In my case, I had just connected external drive. Therefore, for me, everything worked as expected.

I looked closer at the problem and it seems to be quite obvious.

To mount the disk is used pmount. And pmount allows you to mount either discs that have set removable flag (/sys/block/_drive_/removable) or must be explicitly listed in /etc/pmount.allow

Ok, at this point, does it mean that TDE could not receive the necessary modifications to allow mounting non-removable devices for R14?
It means that TDE should use something else than pmount to mount and unmount drives?

-Alexandre

(Odpověď na komentář #8)
> Ok, at this point, does it mean that TDE could not receive the necessary
> modifications to allow mounting non-removable devices for R14?
> It means that TDE should use something else than pmount to mount and unmount
> drives?
> 
> -Alexandre

You could try to replace pmount to udisks/udisks2. Official Debian/Ubuntu packages have udisks/udisks2 support builtin by default.

From what I can tell, Bug 1708 was essentially resolved almost 2 weeks ago by adding udisks2/udisks support to TDE.  Does this new support fix the problem mentioned in this report?

Hi,

I don't have much time these days to test it, but it is pretty easy to test on any dual boot computer. Try to access your Win (or any other linux, data, ...) partition from your TDE linux distro and see if it works.

Hopefully I'll got some free time this weekend to try it.

Have a nice day!
-Alexandre

Latest GIT, Slackware 14.0. I don't have any problems mounting hard disk partitions on my system.

Not a Trinity problem, but my only complaint is the mount point is /run/media/$USER.

Mounting also works for me with kwikdisk.

Do you have pmount installed on your system?  If not then go ahead and close this report.

No pmount here.

I don't think this bug is behind us.

In my fstab I have the following:

/dev/sdb5 /mnt/test ext4 defaults,noauto,noatime,users,exec,rw,suid 0 2

I also have a /dev/sdb6 partition that is not in fstab.

Notice users have mount permissions.

In konqueror, Storage Media, when I select the sdb6 partition and from the popup menu select Mount, the launch feedback icon spins for several seconds. The partition does mount, but my system becomes unstable. When exit Trinity the process takes a long time. I did not time, but perhaps a minute or so. My xsession-error log is filled with several of the following messages:

[dcopserver] DCOP aborting while waiting for answer from 'kded'

When I again in konqueror try to access Storage Media, I see this message:

WARNING: DCOPReply<>: cast to 'bool' error

The end of the xsession log with Trinity terminating contains the following:

ksmserver: WARNING: SmsDie timeout, client twin(10d1dfd7d2000138618353300000286500000)
ksmserver: WARNING: SmsDie timeout, client knotify(10d1dfd7d2000138618353600000286500006)
ksmserver: WARNING: SmsDie timeout, client konqueror(10d1dfd7d2000138618353600000286500008)
ksmserver: WARNING: SmsDie timeout, client (10d1dfd7d2000138618376300000286500019)
ksmserver: WARNING: SmsDie WM timeout

On my system this process is repeatable.

My first guess would be that the udisks/udisks2 code does not check for an error response from DBUS (granted, not the easiest thing to do!), then proceeds to execute bad commands.  Second guess would be the DBUS call itself hanging (somewhat rare, but I have seen it happen before).

(Odpověď na komentář #17)
> My first guess would be that the udisks/udisks2 code does not check for an
> error response from DBUS (granted, not the easiest thing to do!), then proceeds
> to execute bad commands.  Second guess would be the DBUS call itself hanging
> (somewhat rare, but I have seen it happen before).

DBus calls are with udisks/udisks2 used only to eject. While mounting is used standard run the command udisks / udisksctl - the same way as used for pmount.

Therefore to mount are not used any dbus calls - for all supported backends.

OK, good to know, though technically the commands you listed are using DBUS calls internally, so it is still possible for DBUS to be causing major problems.

Darrell, when your system becomes unstable after a failed mount attempt, are there any udisks processes running (e.g. ps aux | grep udisks), ignoring the main udisks daemon?

Thanks!

(Odpověď na komentář #19)
> OK, good to know, though technically the commands you listed are using DBUS
> calls internally, so it is still possible for DBUS to be causing major
> problems.
> 
> Darrell, when your system becomes unstable after a failed mount attempt, are
> there any udisks processes running (e.g. ps aux | grep udisks), ignoring the
> main udisks daemon?
> 
> Thanks!

Yes, udisks/udisksctl internally likely use dbus calls, but that's their problem => error with dbus calls can not be on our side :)

I am unable to replicate this behavior on another system. I have been trying to discern the exact repeatable behavior on the affected system and learn the true root cause.

In the mean time, some observations:

1. In Konqueror Storage Media, in the Name column, all hard drive partitions are identified as Removable Devices. I was unaware that hard drive partitions were removable. In the File Type column the devices are identified as Mounted/Unmounted Hard Disk Volume. Can we fix this? For example, Fixed Device? Unremovable Device?

2. On two of my systems I have unmounted partitions, used for testing. All are 20GB. In Konqueror I am unable to tell which partition is which. The Properties option in the popup menu does not inform me. Can we fix this?

3. In the Konqueror popup menu, the Open With option lists --- Audacious?

4. Konqueror mounting/unmounting are inconsistent with the command line. On one system I have sdb5 and sdb6 testing partitions. In my fstab, sdb5 is mountable by users. sdb6 is not in fstab. In Konqueror I can mount and unmount either partition. According to the mount command in a terminal, sdb6 gets mounted through Konqueror as writable (rw,nosuid,nodev,uhelper=udisks2). Yet toggle to the terminal and type 'umount /dev/sdb6' and the umount command responds 'umount: /dev/sdb6 is not in the fstab (and you are not root)'. I suspect this will be confusing to many users.

More to follow!

Point #4 is not TDE specific--udisks/udisk2 is the culprit, and all modern desktop environments (i.e. those that use udisks/udisks2) will behave the same way.

As mentioned previously, on one system sdb5 is in fstab and mountable by users. sdb6 is not in fstab.

1. In Konqueror Storage Media, I can mount sdb6 with no incidents. The mount survives exiting Trinity. This does not seem appropriate to me, especially since the mount point is defined by the user at /run/media/$USER/$UUID. And for whatever reason, the partition is mounted rw.

2. I can mount sdb5 using the command line or kwikdisk and see no problems. When I mount sdb5 using Konqueror Storage Media, I see my system go snaky. The taskbar icon spins until timing out. When I change directories in Konqueror, such as to $HOME, and change the navigation pane to Root Folder, then immediately toggle the navigation pane to Services Storage Media, I get a blank file pane. Then trying to exit Trinity takes a long time. Opening the File/Open dialog in kate results in the dialog toolbar not appearing for a second or two.

The problems occur with mounting the partition that users have permission rather than the one they don't have permission.

To verify, I commented out sdb5 in fstab and restarted Trinity. Then in Konqueror I could mount/unmount either sdb5/sdb6 without incident.

On the other system that previously I could not replicate the problem, I added an fstab entry for one of the testing partitions. Sure enough, when I tried to use Konqueror to mount the partition listed in fstab, my desktop went snaky.

Seems then Konqueror mounting options has a problem with partitions listed in fstab.

I also saw this message in the xsession log, although I don't know the exact point the message triggered:

WARNING: DCOPReply<>: cast to 'TQCString' error

I know there is some code in TDE to handle the fstab case separately from a normal removable device, however can you see if udisks2 will even let you mount a partition that is listed in /etc/fstab as a normal user?  d-feet provides a GUI from which you can make the appropriate DBUS call.

Thanks!

How do I mount something with udisks2? I'm not finding anything online.

Does TDE require fuse?

Are there any special policy files required that I might not have installed?

(In reply to comment #25)
> How do I mount something with udisks2? I'm not finding anything online.

In d-feet find the appropriate block device, then find the mount method and execute it by double clicking on it.

> Does TDE require fuse?

Not directly, but possibly indirectly through udisks/udisks2.

> Are there any special policy files required that I might not have installed?


Unknown; that wouldn't be a TDE problem anyway. ;-)

Tim

>In d-feet find the appropriate block device, then find the mount method and
>execute it by double clicking on it.
I don't know whether I performing this correctly. When I double-click, I dialog appears and I select the Execute button. The dialog shows this in the Output window:

'More items found in D-Bus signature than in Python arguments'

Hi,

I couldn't test it in exactly the same situation (I was on another computer...), but it seems to work properly.

Thanks!
-Alexandre

My tests indicate that udisks(2) will not allow a non-root user to mount a partition specified in /etc/fstab.  I have seen this behaviour often enough that I am fairly certain it is common between all desktops/mount helpers, even though it may not be an official standard.

udisks(2) spits back a very descriptive error message, which TDE then displays.  It explicitly states that "only root can mount /dev/sd<x><n>".

In light of this, can this report be closed, or is there another part of it that still needs to be addressed?

Konqueror becomes useless after I try to mount a partition listed in fstab. If udisks(s) is the cause then how about adding some idiot proofing to Trinity to work around the problem? Can Trinity be massaged to wrap around the refusal to mount?

The folks at Red Hat have a problem. They keep reinventing the wheel and everybody downstream keeps paying the price. I'm growing tired of their shenanigans to rule the free/libre software world.

To clarify, when udisks refuses to mount, have Trinity display a dialog explaining the problem with mounting, but ensure Konqueror does not go bonkers in a manner that requires restarting Trinity.

(In reply to comment #30)
> Konqueror becomes useless after I try to mount a partition listed in fstab. If
> udisks(s) is the cause then how about adding some idiot proofing to Trinity to
> work around the problem? Can Trinity be massaged to wrap around the refusal to
> mount?

Well, that is definitely NOT supposed to happen!  Are you using udisks or udisks2?

It would also be helpful to see if there is a 'udisks' or 'udisksctl' command running while Konqueror is frozen.  If so, I have no choice but to implement proper DBUS hooks to udisks(2) instead of using the command line programs.

> The folks at Red Hat have a problem. They keep reinventing the wheel and
> everybody downstream keeps paying the price. I'm growing tired of their
> shenanigans to rule the free/libre software world.

No kidding!  Their slow software is one of the main reasons I use Debian (used to use Ubuntu, but then Canonical did the same thing).

>Well, that is definitely NOT supposed to happen!
Refer to comment 21 and comment 23.

>Are you using udisks or udisks2?
Both are installed in recent Slackwares:

udisks-1.0.4
udisks2-1.98.0

I compile tdelibs:

-DWITH_UDISKS=ON
-DWITH_UDISKS2=ON

(In reply to comment #33)
> >Well, that is definitely NOT supposed to happen!
> Refer to comment 21 and comment 23.

OK.  I wonder if udisks2 (which is preferentially used if both versions are available) is trying to gain root access with a prompt on the command line.  Can you look for a running udisksctl process while Konqueror is hung after a failed mount attempt?

Thanks!

The mount doesn't fail. While mounting  the task bar icon spins a long time.

All I see in ps:

/usr/lib/udisks2/udisksd --no-debug

After mounting an fstab partition in konqueror, thereafter konqueror takes much longer to launch/start, despite being preloaded.

Also, I am unable to logout/exit Trinity after mounting the partition through konqueror. I have to use Ctrl-Alt-Backspace.

Odd thing is I can use kwikdisk to mount and unmount the same partition that is listed in fstab. All day long, with no ill effects. Only when mounting through konqueror does my system start misbehaving.

For mounts defined in fstab, why not use the kiwikdisk code rather than usdisks?

If defined in fstab
  use kwikdisk code
else
  use udisks

(In reply to comment #37)
> For mounts defined in fstab, why not use the kiwikdisk code rather than
> usdisks?
> 
> If defined in fstab
>   use kwikdisk code
> else
>   use udisks

Is kwikdisk a KDE4 application?

I modified the TDE HW library some time ago to directly call udisks(2) via DBUS (GIT hash 6d8bcb62); did you notice any change in behavior?

kwikdisk is part of tdeutils, part of kdf (kdiskfree), and can be run from the System menu.

The behavior still exists and is worse. Now I can't mount the fstab partition at all from within konqueror. I still have to restart Trinity to regain normal usage of konqueror.

Having to force a Trinity restart to regain normal usage of konqueror is bad, but the fact that a user is allowed to mount a partition not defined in fstab but then is not allowed to unmount the same partition, although likely a udisks behavior, is just plain silly.

I confirm the bug, exactly as described by Darrell in comment 16

(In reply to Darrell from comment #16)
> I don't think this bug is behind us.
> 
> In my fstab I have the following:
> 
> /dev/sdb5 /mnt/test ext4 defaults,noauto,noatime,users,exec,rw,suid 0 2
> 
> I also have a /dev/sdb6 partition that is not in fstab.
> 
> Notice users have mount permissions.
> 
> In konqueror, Storage Media, when I select the sdb6 partition and from the
> popup menu select Mount, the launch feedback icon spins for several seconds.
> The partition does mount, but my system becomes unstable. When exit Trinity
> the process takes a long time. I did not time, but perhaps a minute or so.
> My xsession-error log is filled with several of the following messages:
> 
> [dcopserver] DCOP aborting while waiting for answer from 'kded'
> 
> When I again in konqueror try to access Storage Media, I see this message:
> 
> WARNING: DCOPReply<>: cast to 'bool' error
> 
> The end of the xsession log with Trinity terminating contains the following:
> 
> ksmserver: WARNING: SmsDie timeout, client
> twin(10d1dfd7d2000138618353300000286500000)
> ksmserver: WARNING: SmsDie timeout, client
> knotify(10d1dfd7d2000138618353600000286500006)
> ksmserver: WARNING: SmsDie timeout, client
> konqueror(10d1dfd7d2000138618353600000286500008)
> ksmserver: WARNING: SmsDie timeout, client
> (10d1dfd7d2000138618376300000286500019)
> ksmserver: WARNING: SmsDie WM timeout
> 
> On my system this process is repeatable.

My best guess at the moment given this information is that something is causing the udisks(2) DBUS call to hang and never return.  I am currently setting up a test system to analyze this further.

Tim

Apologies for the delay; I was called away to other tasks over the weekend.

The code in tdebase/tdeioslave/media/mediamanager/tdehardwarebackend.cpp:1158 is the culprit.  It looks like I wrote that malfunctioning section to begin with, so I will rewrite it properly as soon as I can. :-)

The Konqueror hang on double-clicking an unmounted fstab-specified media device has been resolved in GIT hash 5f270bc.  I am still tracing a subsequent hang on going up one level from the newly mounted device.

(In reply to Timothy Pearson from comment #44)
> The Konqueror hang on double-clicking an unmounted fstab-specified media
> device has been resolved in GIT hash 5f270bc.  I am still tracing a
> subsequent hang on going up one level from the newly mounted device.

On subsequent investigation it seems that a regression has been introduced at some point whereby traversing media:/ tdeioslave directories requires a second identical traversal request to be made before it will complete.  For example, I can go "up" only by double-clicking the "up" button.

I don't remember this happening before a few weeks ago, but due to the QuickBuild outage happening in that timeframe the actual offending commit might be from a few weeks before that.

A bisect indicates the offending commit is tdelibs 6f56182:
http://git.trinitydesktop.org/cgit/tdelibs/commit/?id=6f5618209f0db9bd4ef170126ac618ecc7c68763

Once the fault introduced in that commit is repaired I think this report will (finally!) be resolved.

Created attachment 2021 [details]
Fix directory traversal problem

This patch repairs the directory traversal problem, but likely reopens Bug 1902.  Given that this is a very user-visible bug which severely affects the day-to-day use of the media TDEIO slave, versus Bug 1902 which is hidden in the background for the most part, I would like to push this patch to GIT.

Thoughts?

(In reply to Timothy Pearson from comment #47)
I haven't look at the details of the two bugs, but I would choose to fix this one first since it affects day-to-day usability and then look at 1902 for a different fix. Just my 2 cents.

(In reply to Michele Calgaro from comment #48)
> (In reply to Timothy Pearson from comment #47)
> I haven't look at the details of the two bugs, but I would choose to fix
> this one first since it affects day-to-day usability and then look at 1902
> for a different fix. Just my 2 cents.

OK, I just wanted confirmation before pushing.  Patch pushed to GIT in hash fd930ef.

Darrell, et al, can you check to see if the mount behaviour is now fixed?

Thanks!

Yes, it looks like removing the "slaveDone" fixes the directory traversal issue of removable media.
But as you said, it instantly reopens bug 1902 :-)

Even when browsing my locally mounted USB device, I have lots of tdeio_file and tdeio_media processes that are spawned ! (no need to use network protocols like ftp or sftp).

I'm looking it now.

I haven't looked much into bug 1902, but is it possible the slave is terminated with jobDone() but not properly removed from the pool, so Konqueror doesn't know it needs to restart the slave?

In any case we should probably continue this discussion on the appropriate bug report. ;-)

With respect to comment 16, I no longer experience stalls with mounting and unmounting or exiting Trinity, regardless of whether the partition is or is not in fstab.

With respect to comment 21:

* All hard drive partitions are still identified as Removable Devices, which to me is weird and incorrect.

* In Konqueror I am unable to tell which partition is which when the partition sizes are the same.

(In reply to Darrell from comment #52)
> With respect to comment 16, I no longer experience stalls with mounting and
> unmounting or exiting Trinity, regardless of whether the partition is or is
> not in fstab.

Great!

> With respect to comment 21:
> 
> * All hard drive partitions are still identified as Removable Devices, which
> to me is weird and incorrect.

Can you post a screenshot?  That is somewhat strange.  I would also be interested in a screenshot of the TDEControl "Hardware Device Manager" module after double-clicking on one of the offending disk devices.

> * In Konqueror I am unable to tell which partition is which when the
> partition sizes are the same.

Yeah, I was noticing that myself on the test system.  Thoughts on how this should be handled?

Created attachment 2028 [details]
Screen shot of all devices being identified as Removable Device.

>Can you post a screenshot?
See attached.

The double listing in the sidebar is noted in bug 1764.

>Yeah, I was noticing that myself on the test system.  Thoughts on how this
>should be handled?
Hard drives should be identified as Fixed Device rather than Removable Device. In either case, after the word 'Device' add a parenthetical with the device partition, such as (sda1), (sdb2), (sde5), etc.

Created attachment 2029 [details]
Example disk info window

Thanks for the screenshot.  I am looking for another screenshot something like this one, and it might help if you also posted another screenshot with the Details tab selected.  This should give me enough information to figure out why TDE is thinking your hard disk is a removable device.

Created attachment 2030 [details]
Disk info window screen shot

>I am looking for another screenshot
See attached.

When I attempt to open the Hardware Device Manager module through Menu->Control Center->Peripherals->Hardware Device Manager, I am presented with a dialog to enter root's password. The command being run is 'tdecmshell hwmanager'. I am presented with no such dialog when I access the module directly from within KControl. Further, when I enter the password and the module window opens, double-clicking on any item results in an error message 'Detailed information is not available for this device'.

(In reply to Darrell from comment #56)
> Created attachment 2030 [details]
> Disk info window screen shot
> 
> >I am looking for another screenshot
> See attached.
> 
> When I attempt to open the Hardware Device Manager module through
> Menu->Control Center->Peripherals->Hardware Device Manager, I am presented
> with a dialog to enter root's password. The command being run is 'tdecmshell
> hwmanager'. I am presented with no such dialog when I access the module
> directly from within KControl. Further, when I enter the password and the
> module window opens, double-clicking on any item results in an error message
> 'Detailed information is not available for this device'.

Did you expand the Disk tree item and double-click on one of the incorrectly-labelled "removable" media devices?  Double-clicking on one of the root entries (such as "Disk") will lead to the error message you described.

Note that I was incorrect above; the tab name is "Disk" not "Details"

Thanks!

(In reply to Timothy Pearson from comment #57)
> (In reply to Darrell from comment #56)
> > Created attachment 2030 [details]
> > Disk info window screen shot
> > 
> > >I am looking for another screenshot
> > See attached.
> > 
> > When I attempt to open the Hardware Device Manager module through
> > Menu->Control Center->Peripherals->Hardware Device Manager, I am presented
> > with a dialog to enter root's password. The command being run is 'tdecmshell
> > hwmanager'. I am presented with no such dialog when I access the module
> > directly from within KControl. Further, when I enter the password and the
> > module window opens, double-clicking on any item results in an error message
> > 'Detailed information is not available for this device'.
> 
> Did you expand the Disk tree item and double-click on one of the
> incorrectly-labelled "removable" media devices?  Double-clicking on one of
> the root entries (such as "Disk") will lead to the error message you
> described.
> 
> Note that I was incorrect above; the tab name is "Disk" not "Details"
> 
> Thanks!

I don't see anything wrong in the screenshot you posted in attachment 2030 [details] -- the TDE hardware manager has correctly identified the devices as hard disks.  Something must be setting the removable flag; a screenshot of the "Disks" tab might help here.

Thanks!

Created attachment 2031 [details]
Disk tab screen shot

>Did you expand the Disk tree item and double-click on one
>of the incorrectly-labelled "removable" media devices?
>Double-clicking on one of the root entries (such as "Disk")
>will lead to the error message you described.

Okay, I see. Don't double-click on the root item.

Yet when I open the module through Menu->Control Center->Peripherals->Hardware Device Manager I am asked for root's password. When I run 'tdecmshell hwmanager' from the mini cli (Alt+F2) or terminal I am not asked for the password.

I believe the problem is in /opt/trinity/share/applications/tde/hwmanager.desktop:

X-TDE-RootOnly=true

That does not look correct and should be deleted. The source file is tdebase/kcontrol/hwmanager/hwmanager.desktop.

>a screenshot of the "Disks" tab might help here.
Attached. Same disk partition (sdb2) as the previous screen shot.

(In reply to Darrell from comment #54)
> Created attachment 2028 [details]
> Screen shot of all devices being identified as Removable Device.
> 
> >Can you post a screenshot?
> See attached.
> 
> The double listing in the sidebar is noted in bug 1764.
> 
> >Yeah, I was noticing that myself on the test system.  Thoughts on how this
> >should be handled?
> Hard drives should be identified as Fixed Device rather than Removable
> Device. In either case, after the word 'Device' add a parenthetical with the
> device partition, such as (sda1), (sdb2), (sde5), etc.

OK, I can replicate this quite easily.  I just never really noticed it before. ;-)

Regarding the labelling with the partition node, how does this work on modern systems where the device node is not locked to a specific device?  Modern systems use the UUID of the disk in /etc/fstab to get around this, but the disk UUID is too cumbersome to include in the device name in Konqueror.

Thoughts?

>Thoughts?
How about:

ls /dev/disk/by-uuid
lsblk -f
blkid (might require root privileges)

Also:

/dev/by-id and /dev/by-path for additional info.

>Something must be setting the removable flag
Or a logic error in the code?

On my system I see the following:

cat /sys/block/sda/removable
0
cat /sys/block/sdb/removable
0

Both drives are SATA.

Inserting a USB stick yields a result of 1:

cat /sys/block/sde/removable
1

(In reply to Darrell from comment #61)
> >Thoughts?
> How about:
> 
> ls /dev/disk/by-uuid
> lsblk -f
> blkid (might require root privileges)
> 
> Also:
> 
> /dev/by-id and /dev/by-path for additional info.

Right, I can get the UUID easily (in fact the TDE HW manager already has it) but my comment was directed more toward the user-interface end of things.  It is not exactly user friendly to see an icon with a string like "Fixed 2.0GB Disk (93397480-c282-11e3-8a33-0800200c9a66)" under it. ;-)

(In reply to Darrell from comment #62)
> >Something must be setting the removable flag
> Or a logic error in the code?

Yes, that is what I was thinking.  The reason I had you check the Hardware Devices panel in TDEControl was to get some idea of what the TDE HW manager knew about your disks.  From your screenshots I currently think the error is in the media manager tdeioslave instead of the TDE HW library itself.

> It is not exactly user friendly to see an icon with a string like "Fixed 2.0GB
>Disk (93397480-c282-11e3-8a33-0800200c9a66)"
I was not thinking of that kind of display. I was thinking the partition name (sdb1) could be parsed from a /dev/disk/by-uuid look-up (or blkid -f, etc.) and then the partition name would be inserted in the konqueror display.

(In reply to Darrell from comment #64)
> > It is not exactly user friendly to see an icon with a string like "Fixed 2.0GB
> >Disk (93397480-c282-11e3-8a33-0800200c9a66)"
> I was not thinking of that kind of display. I was thinking the partition
> name (sdb1) could be parsed from a /dev/disk/by-uuid look-up (or blkid -f,
> etc.) and then the partition name would be inserted in the konqueror display.

Right, but the partition name is allowed change from boot to boot (admittedly it does not in most cases right now, but it is possible this will change in the future).  The user does not expect their disk names to change, so it might be a point of confusion.

Granted I'm off in a multi-disk scenario at the moment; if the user only has one disk there is no problem.  I can go ahead and add support for this and if something better appears we can switch to it instead.

> Right, but the partition name is allowed change from boot to boot
Correct, but as long as we display the correct partition name it is not an issue IMO.
For example say a partition is /dev/sdb1 (example removable one). Then I reboot and it becomes /dev/sdc1. I would expect to see /dev/sdb1 the first time and /dev/sdc1 the second time.
UUID are way too long and "obtuse" for a user to identify a disk quickly.
Just my 2 cents.

None of us want to use UUID.

Fixed disks are unlikely to change across reboots. I have two hard drives installed in my office system. Across reboots I expect to always see them as sda and sdb and respective partitions always as sdaX and sdbX.

I expect removable USB flash disks to change often. Only a few people have more than one partition on USB sticks and those who do are more than likely to know what they are doing.

Adding '(sdaX)' to the description would still be helpful for the fixed disks. Right now on my system I see a bunch of 20GB (testing) partitions being listed. I have no way of knowing which is which.

BTW, other desktops are no better. The file managers in other desktops use the same dumb XXGB identifiers. No imagination in Linux land I guess.

The incorrect fixed disk labels, missing parition names, and the hwmanager requiring root permissions should all be fixed in GIT hash 2d6096f.  Please test and report back.

For hard drive partitions I now see:

Name                        File Type
xxGB Fixed Disk (dev/sdxy)  (Un)mounted Hard Disk Volume

For removable USB flash sticks I now see:

Name                         File Type
(Whatever name is assigned)  (Un)mounted Removable Medium

I am able to mount devices from within Konqueror and now can unmount the same devices in Konsole.

I noticed a quirk. When in Konqueror (tree view) and I mount a device, the Modified, Permissions, Owner, and Group Columns all populate. When I unmount from Konsole or Konqueror, the File Type description correctly changes to "Unmounted...." the Permissions column changes, the Owner and Group columns clear, and all change immediately. Yet the Modified column does not clear unless I Refresh (F5). This happened before the recent commit too.

Just a quirk unless you have a clue to fix. I am not worried about this.

Somebody else should verify the patch before closing the bug report. Seems like a good job to me. Thanks. :)

(In reply to Darrell from comment #69)
> For hard drive partitions I now see:
> 
> Name                        File Type
> xxGB Fixed Disk (dev/sdxy)  (Un)mounted Hard Disk Volume
> 
> For removable USB flash sticks I now see:
> 
> Name                         File Type
> (Whatever name is assigned)  (Un)mounted Removable Medium
> 
> I am able to mount devices from within Konqueror and now can unmount the
> same devices in Konsole.
> 
> I noticed a quirk. When in Konqueror (tree view) and I mount a device, the
> Modified, Permissions, Owner, and Group Columns all populate. When I unmount
> from Konsole or Konqueror, the File Type description correctly changes to
> "Unmounted...." the Permissions column changes, the Owner and Group columns
> clear, and all change immediately. Yet the Modified column does not clear
> unless I Refresh (F5). This happened before the recent commit too.
> 
> Just a quirk unless you have a clue to fix. I am not worried about this.
> 
> Somebody else should verify the patch before closing the bug report. Seems
> like a good job to me. Thanks. :)

Quirk fixed in GIT hash 8b10315.  Sharp eyes you have there. ;-)

Sorry it took so long to get this fixed!

Tim

Created attachment 2036 [details]
hardware device manager disk section

I tested the latest code. I can now mount/unmount from Konqueror as described by Darrell.
Nevertheless the hardware device manager still shows a list of partition all with the same names, no indication of the mount point.
Something like /dev/sda1 or /dev/sdb5 or whatever the mount point is should be displayed near the name.
Actually the best IMO would be something like

/dev/sda1 (WDC WD-blah blah blah or whatever your disk is called).

We should not close this bug until this is implemented.

(In reply to Michele Calgaro from comment #71)
> Created attachment 2036 [details]
> hardware device manager disk section
> 
> I tested the latest code. I can now mount/unmount from Konqueror as
> described by Darrell.
> Nevertheless the hardware device manager still shows a list of partition all
> with the same names, no indication of the mount point.
> Something like /dev/sda1 or /dev/sdb5 or whatever the mount point is should
> be displayed near the name.
> Actually the best IMO would be something like
> 
> /dev/sda1 (WDC WD-blah blah blah or whatever your disk is called).
> 
> We should not close this bug until this is implemented.

OK, this is fixed in GIT hashes 142e058 (tdelibs) and 6b07b19 (tdebase).  Note that the proper implementation of this feature required a tdehwlib ABI change, so you will need to recompile/reinstall tdelibs, tdebase, tdepowersave, tdenetworkmanager, and any other modules that link against tdehwlib.

As an aside, this request (a problem with the TDE hardware manager control center module) is vastly different than (and barely related to) the original bug report.  I am not sure reopening this report was the correct thing to do, but I have implemented the feature anyway as it seems to be a valid request.

> As an aside, this request (a problem with the TDE hardware manager control 
> center module) is vastly different than (and barely related to) the original 
> bug report.  I am not sure reopening this report was the correct thing to do,
In hindsight, I agree with you. It would have been better to open a separate bug report for that.
I am going to run a full rebuild tonight, so I will test the new patches tomorrow.

That works great! Well done Tim.