2 Sep
2012
2 Sep
'12
6:05 a.m.
Now that I have a Mounting tab I can see why we were not communicating fully in the
previous thread. :-) I'm starting a new thread so we start on the same page.
With that dialog enabled, I now see you are using UUIDs in mediamanagerrc. I was unable to
see that previously because without the underlying code being compiled that caused the
missing Mounting tab, those features of TDEHW were not working. :-)
I don't know your TDEHW FIXME to-do list. So please accept my apology if I am covering
topics you already know. :-)
* You already know about the problem of retaining the same icon label across different
physical ports. Now that I have access to device-specific mounting options, I can see that
mediamangerrc contains mounting options per UUID, but TDEHW remains confused about
applying icon labels. From what I think I see after multiple insertions/removals of the
same device across three different USB ports, TDEHW is assigning icon labels based upon
device nodes rather than UUID. You mentioned in a previous post you saw the problem in the
code, so I'll watch for a patch.
* Some features of the Mounting dialog are missing, which are reflected respectively in
mediamanagerrc too. Here are some screenshots, the first set from a HAL system and the
second set from TDEHW:
HAL:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-…
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-hal…
TDEHW:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-…
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-tde…
Missing features:
Generic Mount Options:
Quiet
Filesystem Specific Mount Options:
Flushed IO
Mount as user
Short names
Here is a mediamanagerrc set of HAL configurations:
[/org/freedesktop/Hal/devices/volume_uuid_4840_B9DA]
atime=false
flush=true --> Missing
mountpoint=/media/buffalo_1gb
quiet=false --> Missing
ro=false
shortname=lower --> Missing
sync=false
uid=true --> Missing
utf8=true
Here are the same UUID settings under TDEHW:
[4840-B9DA]
atime=false
automount=true
mountpoint=/media/buffalo_1gb
ro=false
sync=false
use_defaults=false
utf8=true
* Safely Remove does not work. That is, using that option will unmount the device but does
not remove the icon from the desktop.
* Eject does not work with CDs/DVDs.
* Icon appearance times remain weird, some fast, some very slow.
* Does TDEHW poll floppy drives? The floppy Mounting dialog (Unmounted Floppy icon) has a
check box to mount automatically, but the option does not yet seem implemented.
Darrell
2 Sep
2 Sep
7:47 a.m.
New subject: [trinity-devel] TDEHW Summary
Now that I have a Mounting tab I can see why we were
not communicating
fully in the previous thread. :-) I'm starting a new thread so we start on
the same page.
With that dialog enabled, I now see you are using UUIDs in mediamanagerrc.
I was unable to see that previously because without the underlying code
being compiled that caused the missing Mounting tab, those features of
TDEHW were not working. :-)
I don't know your TDEHW FIXME to-do list. So please accept my apology if I
am covering topics you already know. :-)
* You already know about the problem of retaining the same icon label
across different physical ports. Now that I have access to device-specific
mounting options, I can see that mediamangerrc contains mounting options
per UUID, but TDEHW remains confused about applying icon labels. From what
I think I see after multiple insertions/removals of the same device across
three different USB ports, TDEHW is assigning icon labels based upon
device nodes rather than UUID. You mentioned in a previous post you saw
the problem in the code, so I'll watch for a patch.
Patched in GIT hash b18416d.
* Some features of the Mounting dialog are missing,
which are reflected
respectively in mediamanagerrc too. Here are some screenshots, the first
set from a HAL system and the second set from TDEHW:
HAL:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-…
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-hal…
TDEHW:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-…
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-tde…
Missing features:
Generic Mount Options:
Quiet
Filesystem Specific Mount Options:
Flushed IO
Mount as user
Short names
<snip>
Unfortunately those options are disabled on purpose due to limitations in
pmount. Reading the man page (http://pwet.fr/man/linux/commandes/pmount)
for pmount reveals no way to set those options; if someone bugs the
upstream pmount project and they make those options available, those
options can be reenabled in TDE with a few lines of code.
* Safely Remove does not work. That is, using that option will unmount the
device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous comments
indicate that your udev subsystem may not be working as well for some
reason.
* Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
* Icon appearance times remain weird, some fast, some
very slow.
Same as above.
* Does TDEHW poll floppy drives? The floppy Mounting
dialog (Unmounted
Floppy icon) has a check box to mount automatically, but the option does
not yet seem implemented.
Good question! I don't have a floppy drive handy to test with. Remember
though that TDE relies on udev for transmission of all device
plug/unplug/state-change events, so you might be able to find out using
the udevadm monitor command I posted earlier.
Tim
5:28 p.m.
New subject: [trinity-devel] TDEHW Summary
Patched in GIT hash b18416d.
I'll test.
Missing
features:
Generic Mount Options:
Quiet
Filesystem Specific Mount Options:
Flushed IO
Mount as user
Short names
Unfortunately those options are disabled on purpose due to
limitations in pmount. Reading the man page (http://pwet.fr/man/linux/commandes/pmount)
for pmount reveals no way to set those options; if someone
bugs the upstream pmount project and they make those options
available, those options can be reenabled in TDE with a few lines of code.
8:04 p.m.
New subject: [trinity-devel] TDEHW Summary
What do users lose with those missing options?
Nothing of any real importance IMHO.
How about having TDEHW migrate those settings to the
new mediamanagerrc
groups and gray/ghost the options in the dialog? That way users would see
that the settings were migrated but not supported under TDEHW.
This is not easy due to the underlying architecture of the media manager
system. Besides this, it would be confusing to most users to see
greyed-out options for settings that the underlying code cannot support at
this time.
More TDEHW related information:
I see the following messages in my xsession log:
=================================================
trying to create local folder /opt/trinity/share/config/tdehw: Permission
denied
Just ignore this. Eventually the idea is to allow users to configure udev
through that module, but for now it only reads/displays the current system
configuration.
TQSocketNotifier: Invalid socket specified
TQSocketNotifier: Internal error
<snip>
I just pushed two new commits to tdelibs and tdebase; they should resolve
the warnings printed above, as well as restore proper removable media
device icons.
I suspect the FIXME messages are on the TDEHW to-do
list?
Yes. If anyone ever sees these messages, please send them to this mailing
list. They indicate that TDEHWLib did not recognize one or more devices
on your system, and they also include enough information to fix detection.
Tim
9:04 p.m.
New subject: [trinity-devel] TDEHW Summary
Retaining the same icon label across different physical ports now works! :-)
Okay, don't show them in the GUI dialog. How about migrating the entire mediamanagerrc
chunk for each device? Those four options would remain dormant under TDEHW, but would be
there should TDEHW support them.
Observation (a different reason to copy the whole mediamanagerrc chunk for each device):
TDEHW does not grep/inherit HAL settings in mediamanagerrc, requiring users to reconfigure
each device that is different from the defaults. That is, each device under TDEHW defaults
to the defaults. Users have to uncheck the "Use defaults" check box and
reconfigure the device. Not to mention having to reconfigure the icon label. Paper cut
nuisance, especially when we want TDEHW to be as seamless as possible --- the basic idea
of "never breaking external interfaces." As both schemes use UUID I'm hoping
this chunk copying should be straightforward. :-)
Aargh. :-) Rebuild again!
Okay. You have that particular set of FIXME messages in your queue. :-)
More information:
CD/DVDs: Not sure how this works, but the following happens when I insert a disk under
both HAL and TDEHW:
* An icon appears on the desktop. The icon label is the name of the disk label, such as
"Slackware64-current DVD."
* A dialog appears asking me what to do.
Then this happens under HAL:
* The disk mounts to a mount point the same as the disk label, such as
"/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
* The disk mounts to the mount point of "/media/sr0" (Functional but not
pretty)
Is there a way to get TDEHW to use a mount point like under HAL? I do not have anything in
mediamanagerrc for optical disks. I don't know how TDE/HAL creates/uses a mount point
that matches the disk label. I'm guessing something in the halbackend code that can be
copied/pasted into the tdehwbackend code? :-)
* Compact flash disk icon: USB device rather than sd_mmc device: I'll test with the
latest patches.
Darrell
How about
having TDEHW migrate those settings to the new mediamanagerrc
groups and gray/ghost the options in the dialog? That way users would see
that the settings were migrated but not supported under TDEHW.
This is not easy due to the underlying architecture of the
media manager system. Besides this, it would be confusing to most
users to see greyed-out options for settings that the underlying code
cannot support at this time.
TQSocketNotifier: Invalid socket specified
TQSocketNotifier: Internal error
I just pushed two new commits to tdelibs and tdebase; they
should resolve the warnings printed above, as well as restore proper
removable media device icons. I suspect the
FIXME messages are on the TDEHW to-do list?
Yes. If anyone ever sees these messages, please send
them to this mailing list. They indicate that TDEHWLib did not recognize
one or more devices on your system, and they also include enough information to
fix detection.
10:33 p.m.
New subject: [trinity-devel] TDEHW Summary
CD/DVDs: Not sure how this works, but the following
happens
when I insert a disk under both HAL and TDEHW:
* An icon appears on the desktop. The icon label is the name
of the disk label, such as "Slackware64-current DVD."
* A dialog appears asking me what to do.
Then this happens under HAL:
* The disk mounts to a mount point the same as the disk
label, such as "/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
* The disk mounts to the mount point of "/media/sr0"
(Functional but not pretty)
Is there a way to get TDEHW to use a mount point like under
HAL? I do not have anything in mediamanagerrc for optical
disks. I don't know how TDE/HAL creates/uses a mount point
that matches the disk label. I'm guessing something in the
halbackend code that can be copied/pasted into the
tdehwbackend code? :-)
I tested this under Xfce 4.10 and KDE 4.8.5. The mount point is the same as the disk
label, just like TDE under HAL. For example "/media/Slackware64-current DVD." We
probably want to be consistent and do the same?
* Compact flash disk icon: USB device rather than
sd_mmc
device: I'll test with the latest patches.
This is fixed. :-)
Darrell
10:38 p.m.
New subject: [trinity-devel] TDEHW Summary
CD/DVDs: Not
sure how this works, but the following happens
when I insert a disk under both HAL and TDEHW:
* An icon appears on the desktop. The icon label is the name
of the disk label, such as "Slackware64-current DVD."
* A dialog appears asking me what to do.
Then this happens under HAL:
* The disk mounts to a mount point the same as the disk
label, such as "/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
* The disk mounts to the mount point of "/media/sr0"
(Functional but not pretty)
Is there a way to get TDEHW to use a mount point like under
HAL? I do not have anything in mediamanagerrc for optical
disks. I don't know how TDE/HAL creates/uses a mount point
that matches the disk label. I'm guessing something in the
halbackend code that can be copied/pasted into the
tdehwbackend code? :-)
I tested this under Xfce 4.10 and KDE 4.8.5. The mount point is the same
as the disk label, just like TDE under HAL. For example
"/media/Slackware64-current DVD." We probably want to be consistent and do
the same?
10:57 p.m.
New subject: [trinity-devel] TDEHW Summary
I tested this
under Xfce 4.10 and KDE 4.8.5. The mount point is the same
as the disk label, just like TDE under HAL. For example
"/media/Slackware64-current DVD." We probably want to be consistent and do
the same?
Is this regression specific to CDs/DVDs, or does the same
problem exist with other media as well? I never paid too much
attention to how HAL handled default mount points...
10:42 p.m.
New subject: [trinity-devel] TDEHW Summary
Safely Remove
does not work. That is, using that option will unmount the
device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous
comments indicate that your udev subsystem may not be working as well
for some reason.
* Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
10:46 p.m.
New subject: [trinity-devel] TDEHW Summary
Safely Remove does not work. That is, using that
option will unmount
the
device but does not remove the icon from the
desktop.
Likely a udev/eject problem; it works here but your previous
comments indicate that your udev subsystem may not be working as well
for some reason.
* Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
10:50 p.m.
New subject: [trinity-devel] TDEHW Summary
Safely Remove
does not work. That is, using that option will unmount
the
device but does not remove the icon from the
desktop.
Likely a udev/eject problem; it works here but your previous
comments indicate that your udev subsystem may not be working as well
for some reason.
* Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
11:02 p.m.
New subject: [trinity-devel] TDEHW Summary
More information: TDE handles a HAL eject and a
TDEHWLib
eject the exact same way, via a call to kdeeject, which then calls
eject. As eject used to rely on HAL, I would not be a bit surprised if the
'eject' binary is broken on Slackware 14 (the ioctl errors would support this
hypothesis).
At this point I don't think eject is broken. As mentioned in a previous post, eject
and icon disappearance is working on Slackware 14 with Xfce 4.10 and KDE 4.8.5. More,
Slackware 14 is being heavily tested by many people and nobody is reporting breakage with
eject.
As I mentioned, for the moment I'm suspecting a not-so-obvious build issue. I
don't see any kdebug options to monitor kdeeject. I suppose I could temporarily enable
all kdebug options and then watch stdout.
Darrell
11:16 p.m.
New subject: [trinity-devel] TDEHW Summary
More
information: TDE handles a HAL eject and a TDEHWLib
eject the exact same way, via a call to kdeeject, which then calls
eject. As eject used to rely on HAL, I would not be a bit surprised if
the
'eject' binary is broken on Slackware 14 (the ioctl errors would support
this
hypothesis).
At this point I don't think eject is broken. As mentioned in a previous
post, eject and icon disappearance is working on Slackware 14 with Xfce
4.10 and KDE 4.8.5. More, Slackware 14 is being heavily tested by many
people and nobody is reporting breakage with eject.
3 Sep
3 Sep
12:46 a.m.
New subject: [trinity-devel] TDEHW Summary
Can you try using kdeeject from the command line on
your CD
drive to see if it works at all?
I tried, The result was an OK button dialog, "Eject failed!" I had everything in
kdebugdialog enabled and I could not find anything related.
That "Eject failed!" dialog should provide some verbose information about the
failure, or provide a "More details" button to provide why the command failed.
Darrell
2 Sep
2 Sep
11:20 p.m.
New subject: [trinity-devel] TDEHW Summary
Does 'eject' work from the command line at all
on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I insert a disk.
When I insert a disk and the drive tray closes, the eject command stops working. When I
use the drive button to eject the disk, the eject command thereafter starts working
again.
Hence my previous comment that there might be some kind of soft lock occuring.
I don't know why this does not happen on your system. Do you build with both
WITH_HAL=ON and WITH_TDEHW=ON? If yes, possibly HAL is grabbing the Eject and Safely
Remove commands rather than TDEHW?
I see that the Safely Remove option is a service type:
Exec=kio_media_mounthelper -s %u
and the Eject command is a service type too:
Exec=kio_media_mounthelper -e %u
Looks like kio_media_mounthelper is a good place to troubleshoot? Perhaps that command
builds differently under WITH_HAL and WITH_TDEHW?
Regarding the CD/DVD mountpoint, I am not entirely
comfortable using the disk volume name as the mountpoint. I am especially
concerned about what might happen if more than one disk uses the same
name--normally this results in a nested mount on Linux, which is NOT what would
be desired in this case.
Yet this is the way TDE creates mount points on a HAL system and has been that way for
years. :-)
How many people have two optical drives on their system and how many people insert two
identical disks with the same volume label? That would be one heck of an unusual corner
case. :-)
I have a spare box with both a CD reader and a DVD burner that has both KDE3 and TDE
installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the other desktops
with this one feature will go over well with users. I hate WTF moments. :-)
Darrell
11:31 p.m.
New subject: [trinity-devel] TDEHW Summary
Does
'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive
tray --- until I insert a disk. When I insert a disk and the
drive tray closes, the eject command stops working. When I
use the drive button to eject the disk, the eject command
thereafter starts working again.
Hence my previous comment that there might be some kind of
soft lock occuring.
I don't know why this does not happen on your system. Do you
build with both WITH_HAL=ON and WITH_TDEHW=ON? If yes,
possibly HAL is grabbing the Eject and Safely Remove
commands rather than TDEHW?
I see that the Safely Remove option is a service type:
Exec=kio_media_mounthelper -s %u
and the Eject command is a service type too:
Exec=kio_media_mounthelper -e %u
Looks like kio_media_mounthelper is a good place to
troubleshoot? Perhaps that command builds differently under
WITH_HAL and WITH_TDEHW?
3 Sep
3 Sep
12:43 a.m.
New subject: [trinity-devel] TDEHW Summary
I'm looking at
tdebase/kioslave/media/mediamanager/CMakeLists.txt. I notice
two differences:
Under WITH_HAL, linuxcdpolling.cpp is built but not
otherwise. Second, under WITH_HAL, the LINK option includes
${DBUS_TQT_LIBRARIES} but otherwise not.
In other words, when building with WITH_HAL=OFF and
WITH_TDEHW=ON, those two differences come into play.
I could try a simple patch to add those options and see what
happens. Worse case is tdebase fails to build.
The patch did not help. Did not hinder either.
Built without failure too. Interesting.
Darrell
2 Sep
2 Sep
11:32 p.m.
New subject: [trinity-devel] TDEHW Summary
Does
'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I
insert a disk. When I insert a disk and the drive tray closes, the eject
command stops working. When I use the drive button to eject the disk, the
eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock
occuring. I have a spare box with both a CD reader and a DVD
burner that has both
KDE3 and TDE installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the
other desktops with this one feature will go over well with users. I hate
WTF moments. :-)
Of course, and I do understand the rationale. However, this corner case
is still a real possibility, and we don't want an even bigger WTF moment
if it is triggered for some reason.
A reasonable compromise might be to include the dev node name at the end
of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we
know how HAL handles this corner case via your test I can try to duplicate
its behaviour as much as possible.
Tim
11:44 p.m.
New subject: [trinity-devel] TDEHW Summary
If ( Name exists)
{
Name = Name + id
}
Mount
On Sep 2, 2012 7:32 PM, "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net>
wrote:
I
Does 'eject' work from the command line at all
on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until insert a disk. When I insert a disk and the drive
tray closes, the eject
command stops working. When I use the drive button to eject the disk, the
eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock
occuring.
But TDE does not have any control over the operation of the
system-provided eject command, nor does it have the ability to lock access
to the CD drive. Can you use the eject command with a CD in the drive
from within KDE4 or XFCE?
I have a spare box with both a CD reader and a
DVD burner that has both
KDE3 and TDE installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the
other desktops with this one feature will go over well with users. I hate
WTF moments. :-)
Of course, and I do understand the rationale. However, this corner case
is still a real possibility, and we don't want an even bigger WTF moment
if it is triggered for some reason.
A reasonable compromise might be to include the dev node name at the end
of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we
know how HAL handles this corner case via your test I can try to duplicate
its behaviour as much as possible.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
11:45 p.m.
New subject: [trinity-devel] TDEHW Summary
Does 'eject' work from the command line at all
on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until
I
insert a disk. When I insert a disk and the drive tray closes, the eject
command stops working. When I use the drive button to eject the disk,
the
eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock
occuring.
3 Sep
3 Sep
12:53 a.m.
New subject: [trinity-devel] TDEHW Summary
This is very likely a kernel problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986845
Slackware 14 is using 3.2.28.
As nobody is reporting eject problems, I don't expect much help from the Slackware
community because Trinity is not an officially supported desktop. Xfce 4.10 and KDE 4.8.5
are officially supported and eject works fine with both.
Darrell
3:24 a.m.
New subject: [trinity-devel] TDEHW Summary
This is very
likely a kernel problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986845
Slackware 14 is using 3.2.28.
As nobody is reporting eject problems, I don't expect much help from the
Slackware community because Trinity is not an officially supported
desktop. Xfce 4.10 and KDE 4.8.5 are officially supported and eject works
fine with both.
Darrell
5:12 a.m.
New subject: [trinity-devel] TDEHW Summary
I understand what you are saying, however AFAIK KDE4
and
Xfce do not use the eject command (they probably use udisks or similar),
therefore I would not expect any problems with 'eject' to be reported even if
they did exist.
I can't fix (or sometimes even work around) core Linux
system problems by modifying TDE... :-)
I'll try to learn more. When I performed the tests in Xfce 4.10 and KDE 4.8.5, I did
not test from the command line. Only through the desktop GUI. If what you say is true,
then a command line test might not prove anything if those desktops do not use the eject
command in any way.
I posted a query to the Slackware forum but I'm not optimistic because Trinity is not
offically supported.
I have some older udev packages I can test. I also could configure udisks not to run or
remove the package altogether to see whether there is a conflict somewhere. I'm
leaning toward something soft locking the devices that prevents kio_media_mounthelper from
working, for both for the Eject action and the Safely Remove action. My gut says whatever
is causing the lock is affecting both since both actions are performed through the
kio_media_mounthelper command. I use the phrase soft lock because the drive eject button
still works. Only the TDE actions fail and only under TDEHW. Once the eject button is
pressed, the eject command works thereafter.
Darrell
6:48 a.m.
New subject: [trinity-devel] TDEHW Summary
I understand
what you are saying, however AFAIK KDE4 and
Xfce do not use the eject command (they probably use udisks or similar),
therefore I would not expect any problems with 'eject' to be reported
even if
they did exist.
I can't fix (or sometimes even work around) core Linux
system problems by modifying TDE... :-)
I'll try to learn more. When I performed the tests in Xfce 4.10 and KDE
4.8.5, I did not test from the command line. Only through the desktop GUI.
If what you say is true, then a command line test might not prove anything
if those desktops do not use the eject command in any way.
12:24 a.m.
New subject: [trinity-devel] TDEHW Summary
<snip>
A reasonable compromise might be to include the dev
node name at the end
of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we
know how HAL handles this corner case via your test I can try to duplicate
its behaviour as much as possible.
Tim
I went ahead and committed logic for this solution into GIT in tdelibs and
tdebase. This preserves pretty mount paths without adding a large chunk
of new path usage counting logic to the media manager.
Tim
2:18 a.m.
New subject: [trinity-devel] TDEHW Summary
A reasonable compromise might be to include the dev
node
name at the end of the mount point in brackets, i.e. "/media/My CD Label
(sr0)". Once we know how HAL handles this corner case via your test I can
try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks had the same
volume label. There were no problems. The mount point names were handled in the same
manner as reported earlier with using default mount names of disk, disk-1, etc. with USB
flash drives. In this case, I ended up with the first disk being mounted at
"/media/Slackware Install1" and the second disk being mounted at
"/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or mindless loop.
I repeated the test on the same machine using an older GIT version of TDE. Of course, like
the 3.5.10 system, that set of packages were built with HAL rather than TDEHW support. The
mount results were the same.
I see you committed some patches, but I will need a couple of days to test TDEHW on the
dual optical disk machine because I have to build 32-bit packages to test. All of my
previous TDEHW testing has been with 64-bit packages.
Darrell
3:22 a.m.
New subject: [trinity-devel] TDEHW Summary
A reasonable
compromise might be to include the dev node
name at the end of the mount point in brackets, i.e. "/media/My CD Label
(sr0)". Once we know how HAL handles this corner case via your test I
can
try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks
had the same volume label. There were no problems. The mount point names
were handled in the same manner as reported earlier with using default
mount names of disk, disk-1, etc. with USB flash drives. In this case, I
ended up with the first disk being mounted at "/media/Slackware Install1"
and the second disk being mounted at "/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or
mindless loop.
I repeated the test on the same machine using an older GIT version of TDE.
Of course, like the 3.5.10 system, that set of packages were built with
HAL rather than TDEHW support. The mount results were the same.
I see you committed some patches, but I will need a couple of days to test
TDEHW on the dual optical disk machine because I have to build 32-bit
packages to test. All of my previous TDEHW testing has been with 64-bit
packages.
Darrell
3:27 a.m.
New subject: [trinity-devel] TDEHW Summary
A reasonable compromise might be to include the dev
node
name at the end of the mount point in brackets, i.e. "/media/My CD
Label
(sr0)". Once we know how HAL handles this corner case via your test I
can
try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks
had the same volume label. There were no problems. The mount point names
were handled in the same manner as reported earlier with using default
mount names of disk, disk-1, etc. with USB flash drives. In this case, I
ended up with the first disk being mounted at "/media/Slackware
Install1"
and the second disk being mounted at "/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or
mindless loop.
I repeated the test on the same machine using an older GIT version of
TDE.
Of course, like the 3.5.10 system, that set of packages were built with
HAL rather than TDEHW support. The mount results were the same.
I see you committed some patches, but I will need a couple of days to
test
TDEHW on the dual optical disk machine because I have to build 32-bit
packages to test. All of my previous TDEHW testing has been with 64-bit
packages.
Darrell
7:42 p.m.
New subject: [trinity-devel] TDEHW Summary
Sorry, I posted the wrong action above. Instead of
commenting out line 999, you would need to replace it with this line of code:
diskLabel = medium->label();
I haven't yet tried a build with the modified line.
The code as-is works great. Using two disk of the same volume label, mounted automatically
as follows:
Slackware Install1 (sr0)
Slackware Install1 (sr1)
No conflicts.
Darrell
5:01 a.m.
New subject: [trinity-devel] TDEHW Summary
OK, thank you for the information. If you want to,
you
can comment out line 999 of file tdehardwarebackend.cpp and see if the
TDEHWLib backend handles the same situation(two identical volume labels)
gracefully or not. If it does, that line of code can be removed from GIT.
I rebuilt tdelibs/tdebase 64-bit. I see what you did with the optical disk mount point
naming. Looks great to me, best of both worlds and satisfies all concerns. Fundamentally,
the previous scheme of appending a number is no different, but the new scheme actually is
nicer and saner. :-)
I plan to run a 32-bit package build set overnight but the final testing will be late
tomorrow at the earliest. The machine with two optical drives is a PII with an IDE hard
drive. V---e---r---y---s---l---o---w to install a full updated package set. :-)
I'll run the first test with line 999 as is. I should see something like this:
Slackware Install1 (hdb)
Slackware Install1 (hdc)
Or something similar.
Unless the old numerical appendage is in the tdehwbackend code, I'm curious to see
what happens with a package rebuilt with line 999 commented out. We'll see how that
goes tomorrow. :-)
Darrell
4260
days inactive
4261
days old
31 comments
3 participants
participants (3)
-
Calvin Morrison -
Darrell Anderson -
Timothy Pearson