[Development] QStorageInfo

[Bo Thorsen]

Den 27-08-2014 10:40, Knoll Lars skrev:
> 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.

I haven't seen anyone ask for info on what type a drive is, if it's not 
local. André did, but when he explained later, he said that what they 
check for is if it's a local drive or not.

The two use cases I saw in this thread were both of the type where they 
checked that storage was on a local drive because something else would 
be too slow. This assumption might be wrong in some cases anyway, so I 
hope they only warn that it might be bad.

 From following the discussion, it sounds like what actually be needed 
is a isLocal() method that return yes, no or unknown/somethingelse. 
That's a bit simpler and has the advantage that we won't have to expand 
on it to be exact when people come up with weird new hybrid solutions.

And this could certainly satisfy Thiago to the point where it would 
always be accurate. Maybe there are cases where a heuristic would offer 
better results than total accuracy - I don't know that. But it is at 
least possible to make sure that the answer is as correct as the OS 
allows it to be. That is harder to do if you want a quad state that 
might grow to quintet, sextet and so on as new types emerge.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu