On 5/22/19 1:37 PM, Max Reitz wrote: >> I don't know if there is an easy way to warn for normal users, but >> silence the warnings if run under test setups to keep 'make check' >> output unchanged (I know we've silenced warnings in the past when we >> detect we are running qtest, but this isn't necessarily the same setup). >> So not a show-stopper for me. > > Hm. That doesn’t sound too bad. I don’t think there is an easy way to > silence the warning in qemu, but we might be able to just modify the test. > > But I don’t even know whether the warnings are even useful or whether > they would just confuse users more than anything. So far, every case I > know where loosening restrictions failed was because the file is just > gone completely. The only purpose of a warning is to show the user that > qemu might have locks on the file that it doesn’t need, so they will > know what’s up if they try to open the file in another qemu instance in > a way that should normally work but suddenly doesn’t. But if the file’s > just gone, you can’t open it in another qemu, so I don’t even know > whether there’s actually any point in warning.
Good point - if we unlink()ed the file, we can't loosen permissions, but neither can anyone else open() it to collide with us :) A network connection going down is a bit harder to justify (it might come back up), but I think it still fits the bill (if we can't loosen permissions, who else can interfere with us?) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
