On 2018-06-26 19:34, Max Reitz wrote: [...]
> So I suppose I'll rename my BDS.backing_file_canonical attempt to > BDS.auto_backing_file, and this will be what the image header contains > (unless we have opened a BDS from it, in which case it will be that > BDS's filename, so it is canonicalized). Update: That seems to go down the drain. We (stupidly) allow taking a backing filename from the image header and then enriching it with options from the command line (so you could take null-co:// from the image header and then the user could give backing.size. I won't comment on how little sense that makes (apart from [1]), but in any case, this means that "we have opened a BDS from it" is very hard to reliably recognize, because you need to find out whether the user has given any strong options for the backing file. That pretty much brings the complexity back to backing_overridden, I'd say. Well, or: Whenever the user has given any backing options, the resulting BDS is categorized as overridden and the filename is not used as a canonicalized version of auto_backing_file. I now pretty much fail to see how any of this is better than backing_overridden, but whatever. Max [1] In fact, it's completely broken, because the user-given backing options only override the backing filename once the user-given options contain "file.filename". So you actually cannot really override anything unless your new backing file has a protocol driver with a "filename" option. Well, you can, but that means creating an own BDS and then giving a reference to that...
signature.asc
Description: OpenPGP digital signature
