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