Description of problem: File based storage code could fail with AttributeError when renaming a directory if the destination name was an existing directory. Version-Release number of selected component (if applicable): 4.16.0 or later. How reproducible: Unknown Reported by pylint.
Adding a test revealed another failure. rename(2) can fail with ENOTEMPTY or EEXIST but the code was checking only the first. If rename(2) failed with EEXIST, oop.os.rename() was failing with: OSError: [Errno 17] File exists If rename(2) failed with ENOTEMPTY, we tried to fallback to the non-atomic rename and failed with: AttributeError: '_IOProcessOs' object has no attribute 'listdir'
Is there a ovirt-level functional effect to this bug? I think that the correct thing for rename() to do is to raise EEXIST, not silently overwrite the destination. Unless there's a very good reason to make our awkward semantics suddenly work, I'd fix outOfProcess to match the POSIX semantics.
(In reply to Dan Kenigsberg from comment #2) > Is there a ovirt-level functional effect to this bug? The only place where this can happen is when deleting a volume. The first step is renaming the volume directory from <uuid> to remove_me_<uuid>. In is flow we don't need the functionality that the code tried to provide. > I think that the correct thing for rename() to do is to raise EEXIST, not > silently overwrite the destination. Unless there's a very good reason to > make our awkward semantics suddenly work, I'd fix outOfProcess to match the > POSIX semantics. I agree, I'll remove the unneeded code, so rename will have the POSIX semantics.
This was merge long time ago, but the bot did not move it to modified because there one of the patches was abandoned.
Hi Nir, are there any steps to reproduce this bug?
We don't know how to reproduce this in normal usage of the system.
(In reply to Nir Soffer from comment #6) > We don't know how to reproduce this in normal usage of the system. According to this comment, moving to VERIFIED without reproducing it.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.