[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