On 29 Aug 2014, at 1:01 PM, Иван Комиссаров wrote: > 29 авг. 2014 г., в 14:46, André Somers <an...@familiesomers.nl> написал(а): > Thiago Macieira schreef op 29-8-2014 06:32: >>> Could be, but I want to be really clear that it should only be local, >>> remote and unknown. I don't want other types like "removable >>> magnetic", "removable optical", "removable solid state", "virtual >>> regular filesystem", "virtual special", etc. >> Just wondering, but what exactly is the problem with providing more >> details if such details are available? A combination of flags "local", >> "removable" and "optical" would be quite informative. >> >> André > > The problem is you can't rely on that information. For example, "optical" is > totally useless on Linux (we can't get that info).
The kernel knows, and so does udevd (http://en.wikipedia.org/wiki/Udev) (it has to know in order to create the device node, /dev/sr0 on my system). But talking to it involves dbus (and we already discussed the "problem" that it's a dependency). My last suggestion was that maybe we can dynamically load /usr/lib/libudisks2.so or /usr/lib/libudev.so.1, either of which has plain C API, right? (Use the dlopen / QLibrary technique, and try not to use APIs that are too new or likely to change later, if there are any such.) Or we can use qdbus via a plugin, or by whatever means such that not having qdbus or not having udevd is not fatal. If any of that fails, it merely means we don't know the type of the disk, and that's what we have the zero flag for. It should work most of the time. But I think udisks only takes care of local volumes, so if there is a drive that udisks doesn't know about, it could be taken as a clue that it might be a network drive. But the current code already shows the protocol as the filesystem if it's a remote drive. http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html#gdbus-property-org-freedesktop-UDisks2-Drive.MediaCompatibility What about btrfs subvolumes, does udisks know about those too? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
