[Development] QStorageInfo

[Knoll Lars]

On 26/08/14 21:00, "Thiago Macieira" <thiago.macieira at intel.com> wrote:

>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.

I agree that there are many complex corner cases where we can’t exactly
know. But let’s not forget about the common case, where we actually can
determine whether the file system is local or not. I think we all agree
that it’s very helpful to many applications to know this. So saying we
don’t help at all here because we can’t solve 100% of the problems is
wrong and not what Qt is about.

So I am all for a tri/quad state here. Local, Remote & Other/Unknown. And
maybe a Special for things such as procfs. Let’s be conservative with it
and rather have a bit too much in Other/Unknown, but let’s also help
people that need the information and give the right answer for the common
cases.

So I’d say let’s add the enum and getters for it. We can have a default
implementation that returns Unknown, and then reimplement it on each
platform to do something more sensible.

Cheers,
Lars