[Development] QStorageInfo
Thiago Macieira
thiago.macieira at intel.com
Tue Aug 26 21:00:41 CEST 2014
On Tuesday 26 August 2014 12:58:41 Kuba Ober wrote:
> > Unless we want to make this a tri-state: definitely local, definitely
> > remote, could be either.
>
> Absolutely. It’s not even an option not to distinguish those three states.
> The consumer of this data can then decide which side to err on if it wishes
> to be conservative. It also allows the application to query the user for a
> clarification, if necessary. This is definitely an enum, not a bool.
I want to be clear: this should be very restrictive. We can't simply add this
to a list of other flags about the storage, because otherwise people won't
understand that they *must* handle the couldn't-decide case.
At most, we could make it a tetra-state (or is it quadri-state?):
local, virtual, remote, unknown
But I think that's a bad idea because it introduces even more confusion. Is a
FUSE-based filesystem local, virtual or remote? It can be any of them. Besides,
all of Linux's procfs, sysfs and tmpfs are virtual, yet tmpfs should be
treated like a regular filesystem. Or a unionfs mount.
And then there are bind mounts...
Oh, did we mention btrfs subvolumes? QStorageInfo currently has a bug there.
Btrfs subvolumes are mount points not listed in /etc/mnttab.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list