[Development] QStorageInfo

[Lorn Potter]

On 27/08/2014 9:56 pm, Bo Thorsen wrote:
> 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.

I agree something simpler like this would be better. As mentioned 
previously, detecting remote drives on all platforms is not fool proof, 
and hard to implement and I am not sure it's worth trying to get all the 
niche cases fixed.

Heck just figuring out if its a usb drive is not 100% for sure.

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


-- 
Lorn 'ljp' Potter
Software Engineer, llornkcor technologies / Jolla
Qt Sensors / connectivity