Drive Information

[Иван Комиссаров]

I've written class for receiving different information about drives present in filesystem (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h)
Class is implemented for Windows, Mac OS, Linux and Symbian and implementation is better than in QtMobility.

Does Qt5 needs this functionality?

In fact, it seems that such classes exists in libsolid, but why not to move code to QtCore on platforms supported by Qt?

Also i have class for monitoring of appearance of drives in system (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdrivecontroller.h). This monitoring can be expanded to provide request for application that OS wants to unmount volume (and Qt and app can unregister resources on that drive - for example QFSWatcher still locks flash drives on Win and they can't be unmounted properly; we can monitor requests and free resources correctly)

Ivan.

[x***@nokia.com]

Hi,

Seems your code is more or less similar to the latest implementation (I only briefly looked at the Linux one), but we take different approach for caching.
Your idea for file system type and drive name / label (we have UUID on the other hand, but maybe not as readable as label) seem interesting.

You can check the latest code (still under development, and some more will be published soon) at:
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h

================
Xizhi Zhu (Steven)

Software Engineer @ Qt
Nokia

Mobile: [phone]


-----Original Message-----
From: qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com [mailto:qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com] On Behalf Of ext ???? ??????????
Sent: 07. heinäkuuta 2011 22:07
To: qt5-***@qt.nokia.com
Subject: [Qt5-feedback] Drive Information

I've written class for receiving different information about drives present in filesystem (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h)
Class is implemented for Windows, Mac OS, Linux and Symbian and implementation is better than in QtMobility.

Does Qt5 needs this functionality?

In fact, it seems that such classes exists in libsolid, but why not to move code to QtCore on platforms supported by Qt?

Also i have class for monitoring of appearance of drives in system (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdrivecontroller.h). This monitoring can be expanded to provide request for application that OS wants to unmount volume (and Qt and app can unregister resources on that drive - for example QFSWatcher still locks flash drives on Win and they can't be unmounted properly; we can monitor requests and free resources correctly)

Ivan.
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Иван Комиссаров]

Want to update this conversation:)
What mechanism will be used in qt5?

08.07.2011, в 10:24, <***@nokia.com> <***@nokia.com> написал(а):

Hi,

Seems your code is more or less similar to the latest implementation (I only briefly looked at the Linux one), but we take different approach for caching.
Your idea for file system type and drive name / label (we have UUID on the other hand, but maybe not as readable as label) seem interesting.

You can check the latest code (still under development, and some more will be published soon) at:
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h

================
Xizhi Zhu (Steven)

Software Engineer @ Qt
Nokia

Mobile: [phone]


-----Original Message-----
From: qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com [mailto:qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com] On Behalf Of ext ???? ??????????
Sent: 07. heinäkuuta 2011 22:07
To: qt5-***@qt.nokia.com
Subject: [Qt5-feedback] Drive Information

I've written class for receiving different information about drives present in filesystem (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h)
Class is implemented for Windows, Mac OS, Linux and Symbian and implementation is better than in QtMobility.

Does Qt5 needs this functionality?

In fact, it seems that such classes exists in libsolid, but why not to move code to QtCore on platforms supported by Qt?

Also i have class for monitoring of appearance of drives in system (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdrivecontroller.h). This monitoring can be expanded to provide request for application that OS wants to unmount volume (and Qt and app can unregister resources on that drive - for example QFSWatcher still locks flash drives on Win and they can't be unmounted properly; we can monitor requests and free resources correctly)

Ivan.
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[x***@nokia.com]

Hi,

For storage info in Qt5, we currently have:
allLogicalDrives - use getmntent()
availableDiskSpace - use statfs()
totalDiskSpace - use statfs()
uriForDrive - use BLKID or UDisks (D-Bus)
driveType - use getmntent() directly for RAM, Remote, and CDROM, and /sys/block/*/removable for Internal and Removable
logicalDriveChanged (signal) - monitor changes of the _PATH_MOUNTED file

================
Xizhi Zhu (Steven)

Software Engineer @ Qt
Nokia

Mobile: [phone]

-----Original Message-----
From: qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com [mailto:qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com] On Behalf Of ext ???? ??????????
Sent: 05. elokuuta 2011 23:50
To: qt5-***@qt.nokia.com
Subject: Re: [Qt5-feedback] Drive Information

Want to update this conversation:)
What mechanism will be used in qt5?

08.07.2011, в 10:24, <***@nokia.com> <***@nokia.com> написал(а):

Hi,

Seems your code is more or less similar to the latest implementation (I only briefly looked at the Linux one), but we take different approach for caching.
Your idea for file system type and drive name / label (we have UUID on the other hand, but maybe not as readable as label) seem interesting.

You can check the latest code (still under development, and some more will be published soon) at:
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h

================
Xizhi Zhu (Steven)

Software Engineer @ Qt
Nokia

Mobile: [phone]


-----Original Message-----
From: qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com [mailto:qt5-feedback-bounces+xizhi.zhu=***@qt.nokia.com] On Behalf Of ext ???? ??????????
Sent: 07. heinäkuuta 2011 22:07
To: qt5-***@qt.nokia.com
Subject: [Qt5-feedback] Drive Information

I've written class for receiving different information about drives present in filesystem (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h)
Class is implemented for Windows, Mac OS, Linux and Symbian and implementation is better than in QtMobility.

Does Qt5 needs this functionality?

In fact, it seems that such classes exists in libsolid, but why not to move code to QtCore on platforms supported by Qt?

Also i have class for monitoring of appearance of drives in system (https://gitorious.org/qdrive/qdrive/blobs/master/src/qdrivecontroller.h). This monitoring can be expanded to provide request for application that OS wants to unmount volume (and Qt and app can unregister resources on that drive - for example QFSWatcher still locks flash drives on Win and they can't be unmounted properly; we can monitor requests and free resources correctly)

Ivan.
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Иван Комиссаров]

Thank you for direct links:) In fact, you used classes from QtMobility.
Lets compare 2 APIs:
https://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h
https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h

The main difference is that you use one single class for all drives; i use struct that represents one specific drive.
The advantages you have - only 1 class:), you can monitor drives via same class and you can use easily it from script.
Disadvantages - you have to pass same string for each method to retrieve different information for one drive; your API is not intuitive i think.
In my implementation, i tried to keep API already used in Qt and maid my class very similar to QFileInfo. Also my API is similar to lib solid.

Let i show some example:
void useInfo(QString path, qint64 size, qint64 total, DriveType type) {…}

useInfo(pathToDrive ,
storageInfo->availableDiskSpace(pathToDrive),
storageInfo->totalDiskSpace(pathToDrive)),
storageInfo->driveType(pathToDrive)));

my variant:
QDriveInfo drive(pathToDrive);
useInfo(drive.rootPath(), // real root path, not pathToDrive, which can be folder on drive
drive.bytesAvailable(),
drive.bytesTotal(),
drive.type());

I used only same parameters which both present in your variant and mine. If number of parameters will grow up, you will have hell with passing pathToDrive every time.

Next, my variant uses cache, like QFileInfo (it requires only one call for all 3 sizes - total/available/free), you API makes using cache much harder (public function void clearCache(const QString &drive) to clear cache for specific drive? hmmm).

The other use case is to compare drives - i can specify path to two folders/file and compare if these fs entries belongs to same drive:
QDriveInfo(pathToFolder1) == QDriveInfo(pathToFolder2) That can be useful when moving files - if source and dest on same drive, it's simply QFile::rename, otherwise you need to copy whole file (maybe in thread). Current implementation doesn't allow that.

Notification about appearing of new drives - i think that should be done using separate class, like QFileSystemWatcher. The advantage is that you can add notification about _request_ for eject and perform some actions (free resources - close files, remove FSWatcherMonitoring). In current implementation we will have 2 different use cases in one class - gathering info (1) and monitoring and even controlling (2) (i.e. changing label, mounting/unmouting) of drives.

The only advantage you have is that your class is "scriptable", but we can easily write wrapper - QVariantMap/or class derived from QObject

About dbus - i suggested to merge my class in QtCore in 4.8, but i didn't finished merge request before tech preview. So, in qtcore i couldn't use dubs. But if you have specific module for system info, no one stops me from using it, like you do. So implementation will be almost the same (as far as i remember, there was some bugs in QtMobylity storage info classes, in my code i think everything is tested properly).

In fact, i can add d-bus implementation to my classes and replace current implementation in qtsystems module.

What do you think?

Hi,
http://qt.gitorious.org/qt/qtsystems/trees/master/src/systeminfo
http://developer.qt.nokia.com/wiki/Qt_5.0
Yes, blkid requires root privilege, and I'm not really a fan of D-Bus calls. The other alternative is to retrieve from /dev/disk/, and probably I'll use that later (need to check its stability and availability on different Linux distros).
================
Xizhi Zhu (Steven)
Nokia
Mobile: [phone]
-----Original Message-----
Sent: 08. elokuuta 2011 11:28
To: Zhu Xizhi (Nokia-MP-Qt/Tampere)
Subject: Re: [Qt5-feedback] Drive Information
"Currently have" where? In Qt Mobility? API of QStrorageInfo is awful I believe this functionality should be in QtCore, and you can't use dbus there. As for blkid it seems requires root privileges in most cases.

Post by x***@nokia.com
Hi,
allLogicalDrives - use getmntent()
availableDiskSpace - use statfs()
totalDiskSpace - use statfs()
uriForDrive - use BLKID or UDisks (D-Bus) driveType - use getmntent()
directly for RAM, Remote, and CDROM, and /sys/block/*/removable for
Internal and Removable logicalDriveChanged (signal) - monitor changes
of the _PATH_MOUNTED file
================
Xizhi Zhu (Steven)
Nokia
Mobile: [phone]
-----Original Message-----
Sent: 05. elokuuta 2011 23:50
Subject: Re: [Qt5-feedback] Drive Information
Want to update this conversation:)
What mechanism will be used in qt5?
Hi,
Seems your code is more or less similar to the latest implementation (I only briefly looked at the Linux one), but we take different approach for caching.
Your idea for file system type and drive name / label (we have UUID on the other hand, but maybe not as readable as label) seem interesting.
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstor
ageinfo.h
================
Xizhi Zhu (Steven)
Nokia
Mobile: [phone]
-----Original Message-----
Sent: 07. heinäkuuta 2011 22:07
Subject: [Qt5-feedback] Drive Information
I've written class for receiving different information about drives
present in filesystem
(https://gitorious.org/qdrive/qdrive/blobs/master/src/qdriveinfo.h)
Class is implemented for Windows, Mac OS, Linux and Symbian and implementation is better than in QtMobility.
Does Qt5 needs this functionality?
In fact, it seems that such classes exists in libsolid, but why not to move code to QtCore on platforms supported by Qt?
Also i have class for monitoring of appearance of drives in system
(https://gitorious.org/qdrive/qdrive/blobs/master/src/qdrivecontroller
.h). This monitoring can be expanded to provide request for
application that OS wants to unmount volume (and Qt and app can
unregister resources on that drive - for example QFSWatcher still
locks flash drives on Win and they can't be unmounted properly; we can
monitor requests and free resources correctly)
Ivan.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Till Oliver Knoll]

Post by Иван Комиссаров
Want to update this conversation:)
What mechanism will be used in qt5?
...
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h

Without looking at the code and having followed this discussion from the
beginning, but does "drive information" also include "USB events" such
as "USB Drive has been connected/disconnected"?

That would be of interest to me to have :)

I already looked once into this issue, and have working Windows code.
During research I also found example code for Mac (but have no concrete
references right now).

On Linux my approach would have been using DBus and connecting to some
"hardware abstraction service" (can't remember right now which one that
would have been). Or maybe there is a more "low-level" way on Linux as well?

Anyway, is work being considered in this direction? Off course also
figuring out the name of such a device (memory stick, CD, DVD, ...)
would be nice (I mean the "user defined name" which e.g. in File
Explorer is displayed, or on the Mac desktop etc., e.g. "My USB Stick",
not some technical name which is used under the hood).

Cheers, Oliver

[Иван Комиссаров]

Yes, i have code for all your use-cases https://gitorious.org/qdrive/qdrive/trees/master

Unfortunately, monitoring seems broken on Linux due to reason that mtab is not a fille now, but a symlink to procfs.

Post by Till Oliver Knoll

Post by Иван Комиссаров
Want to update this conversation:)
What mechanism will be used in qt5?
...
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h

Without looking at the code and having followed this discussion from the
beginning, but does "drive information" also include "USB events" such
as "USB Drive has been connected/disconnected"?
That would be of interest to me to have :)
I already looked once into this issue, and have working Windows code.
During research I also found example code for Mac (but have no concrete
references right now).
On Linux my approach would have been using DBus and connecting to some
"hardware abstraction service" (can't remember right now which one that
would have been). Or maybe there is a more "low-level" way on Linux as well?
Anyway, is work being considered in this direction? Off course also
figuring out the name of such a device (memory stick, CD, DVD, ...)
would be nice (I mean the "user defined name" which e.g. in File
Explorer is displayed, or on the Mac desktop etc., e.g. "My USB Stick",
not some technical name which is used under the hood).
Cheers, Oliver

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Petr Vanek]

Post by Иван Комиссаров
Yes, i have code for all your use-cases https://gitorious.org/qdrive/qdrive/trees/master
Unfortunately, monitoring seems broken on Linux due to reason that mtab is not a fille now, but a symlink to procfs.

yep, I played with Ivan's code a bit. It's really nice. Unfortunately the latest linux kernels are different (as he said).
But when/if we can fix it it would be great to include it in Qt...

[Thiago Macieira]

Post by Иван Комиссаров
Yes, i have code for all your use-cases
https://gitorious.org/qdrive/qdrive/trees/master
Unfortunately, monitoring seems broken on Linux due to reason that mtab is
not a fille now, but a symlink to procfs.

It's a real file here.

But monitoring mtab seems wrong in the first place. The code should integrate
with udisks and get the info it needs from udisks.

[Иван Комиссаров]

As far as i know, udisks doesn't emit any signals when drive is mounted (correct me, if i'm wrong), it only notifies about _device_ appearing; which is useless for Qt purposes (it makes sense only if you are writing auto-mounting util)

Post by Thiago Macieira

Post by Иван Комиссаров
Yes, i have code for all your use-cases
https://gitorious.org/qdrive/qdrive/trees/master
Unfortunately, monitoring seems broken on Linux due to reason that mtab is
not a fille now, but a symlink to procfs.

It's a real file here.
But monitoring mtab seems wrong in the first place. The code should integrate
with udisks and get the info it needs from udisks.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Thiago Macieira]

Post by Иван Комиссаров
As far as i know, udisks doesn't emit any signals when drive is mounted
(correct me, if i'm wrong), it only notifies about _device_ appearing;
which is useless for Qt purposes (it makes sense only if you are writing
auto-mounting util)

Device inserted:
signal sender=:1.37 -> dest=(null destination) serial=1592
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceAdded
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=1610
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceAdded
object path "/org/freedesktop/UDisks/devices/sdb1"

Device mounted:
signal sender=:1.37 -> dest=(null destination) serial=1813
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean true
string "FilesystemMount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1814
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "FilesystemMount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1816
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1817
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=1819
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1820
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1

Device ejected:
signal sender=:1.37 -> dest=(null destination) serial=1880
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean true
string "FilesystemUnmount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1881
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "FilesystemUnmount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1882
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1883
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=1885
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1886
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1963
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb"
boolean true
string "DriveEject"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1964
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "DriveEject"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1988
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1989
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1990
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1991
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2010
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=2011
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2059
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceRemoved
object path "/org/freedesktop/UDisks/devices/sdb1"

Device removed:
signal sender=:1.37 -> dest=(null destination) serial=2060
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=2061
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2082
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceRemoved
object path "/org/freedesktop/UDisks/devices/sdb"

[Иван Комиссаров]

Ah, thanks, i'll check later. Seems what i need.

Post by Thiago Macieira

Post by Иван Комиссаров
As far as i know, udisks doesn't emit any signals when drive is mounted
(correct me, if i'm wrong), it only notifies about _device_ appearing;
which is useless for Qt purposes (it makes sense only if you are writing
auto-mounting util)

signal sender=:1.37 -> dest=(null destination) serial=1592
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceAdded
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=1610
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceAdded
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=1813
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean true
string "FilesystemMount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1814
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "FilesystemMount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1816
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1817
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=1819
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1820
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1880
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean true
string "FilesystemUnmount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1881
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "FilesystemUnmount"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1882
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1883
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=1885
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb1"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1886
path=/org/freedesktop/UDisks/devices/sdb1;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1963
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb"
boolean true
string "DriveEject"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1964
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean true
string "DriveEject"
uint32 500
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1988
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceJobChanged
object path "/org/freedesktop/UDisks/devices/sdb"
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1989
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=JobChanged
boolean false
string ""
uint32 0
boolean false
double -1
signal sender=:1.37 -> dest=(null destination) serial=1990
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=1991
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2010
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=2011
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2059
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceRemoved
object path "/org/freedesktop/UDisks/devices/sdb1"
signal sender=:1.37 -> dest=(null destination) serial=2060
path=/org/freedesktop/UDisks/devices/sdb;
interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.37 -> dest=(null destination) serial=2061
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.37 -> dest=(null destination) serial=2082
path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks;
member=DeviceRemoved
object path "/org/freedesktop/UDisks/devices/sdb"
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Sune Vuorela]

Post by Иван Комиссаров
As far as i know, udisks doesn't emit any signals when drive is mounted (correct me, if i'm wrong), it only notifies about _device_ appearing; which is useless for Qt purposes (it makes sense only if you are writing auto-mounting util)

What udisks & udev is doing seems to be good enough for KDE's Solid
library. Or alternatively what Hal is doing , should you be stuck in the
last decade.

/Sune

[Petr Vanek]

Post by Thiago Macieira

Post by Иван Комиссаров
Yes, i have code for all your use-cases
https://gitorious.org/qdrive/qdrive/trees/master
Unfortunately, monitoring seems broken on Linux due to reason that mtab is
not a fille now, but a symlink to procfs.

It's a real file here.

It was introduced with newer linux kernels

***@linux-0lew:~/razor/razor-qt> ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 Mar 17 2011 /etc/mtab -> /proc/self/mounts

***@linux-0lew:~/razor/razor-qt> file /proc/self/mounts
/proc/self/mounts: empty

***@linux-0lew:~/razor/razor-qt> cat /proc/self/mounts
rootfs / rootfs rw 0 0
devtmpfs /dev devtmpfs rw,relatime,size=251480k,nr_inodes=62870,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/sda1 / ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /proc/fs/vmblock/mountPoint vmblock rw,relatime 0 0

***@linux-0lew:~/razor/razor-qt> uname -a
Linux linux-0lew 2.6.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 i686 i686 i386 GNU/Linux

Post by Thiago Macieira
But monitoring mtab seems wrong in the first place. The code should integrate
with udisks and get the info it needs from udisks.

agree. Luckily it looks like udev can handle it without it...

[Thiago Macieira]

Post by Petr Vanek
It was introduced with newer linux kernels

A file in /etc has nothing to do with the kernel. It's the distribution's
choice what to put there.

Post by Petr Vanek
lrwxrwxrwx 1 root root 17 Mar 17 2011 /etc/mtab -> /proc/self/mounts

$ ls -l /etc/mtab
-rw-r--r-- 1 root root 214 Out 15 12:33 /etc/mtab

Post by Petr Vanek
/proc/self/mounts: empty

$ file /proc/self/mounts
/proc/self/mounts: empty

Post by Petr Vanek
Linux linux-0lew 2.6.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 i686
i686 i386 GNU/Linux

$ uname -a
Linux doriath 2.6.38.7-desktop-1mnb2 #1 SMP Sun May 22 21:09:18 UTC 2011 i686
i686 i386 GNU/Linux

[Petr Vanek]

Post by Thiago Macieira

Post by Petr Vanek
It was introduced with newer linux kernels

A file in /etc has nothing to do with the kernel. It's the distribution's
choice what to put there.

ok, may be. But now it seems like standard on all machines I have an access (suse, fedora). But let it be - it's off topic now.