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" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
