we check first that it is a link and only then we unlink it. so it should be fine anyway.
On Sun, Jun 2, 2019 at 3:50 PM Pavel Bar pbar@redhat.com wrote:
On Fri, May 31, 2019 at 4:14 AM Nir Soffer nirsof@gmail.com wrote:
From: Amit Bawer abawer@redhat.com
On storage setup we can have stale symlinks to loop devices which were created before reboot and now are gone. Re-running the setup will fail on creating the symlink again. In this patch we add removal of the pre-existing symlink, if there is such, before symlinking the new loop device.
tests/storage.py | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/tests/storage.py b/tests/storage.py index 3258ed4..ef40f08 100644 --- a/tests/storage.py +++ b/tests/storage.py @@ -82,10 +82,13 @@ def create_loop_device(link_path, backing_file, size=1024**3, "--show", ])
device = out.decode("utf-8").strip()
- #remove stale symlink
- if os.path.islink(link_path):
os.unlink(link_path)As far as I remember in Nir's commits the recommended paradigm was to do a File System action and catch an exception if failed. Thus it can't happen that between testing for the condition and performing an action based on this condition another process already performed the action. Although according to the docs "os.unlink" doesn't throw an exception if the link doesn't exist, also not sure that such a protection is needed here at all.
os.symlink(device, link_path) chown(link_path)def remove_loop_device(link_path, backing_file):
2.17.2
On Sun, Jun 2, 2019 at 5:24 PM Amit Bawer abawer@redhat.com wrote:
we check first that it is a link and only then we unlink it. so it should be fine anyway.
On Sun, Jun 2, 2019 at 3:50 PM Pavel Bar pbar@redhat.com wrote:
On Fri, May 31, 2019 at 4:14 AM Nir Soffer nirsof@gmail.com wrote:
From: Amit Bawer abawer@redhat.com
On storage setup we can have stale symlinks to loop devices which were created before reboot and now are gone. Re-running the setup will fail on creating the symlink again. In this patch we add removal of the pre-existing symlink, if there is such, before symlinking the new loop device.
tests/storage.py | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/tests/storage.py b/tests/storage.py index 3258ed4..ef40f08 100644 --- a/tests/storage.py +++ b/tests/storage.py @@ -82,10 +82,13 @@ def create_loop_device(link_path, backing_file, size=1024**3, "--show", ])
device = out.decode("utf-8").strip()
- #remove stale symlink
- if os.path.islink(link_path):
os.unlink(link_path)As far as I remember in Nir's commits the recommended paradigm was to do a File System action and catch an exception if failed. Thus it can't happen that between testing for the condition and performing an action based on this condition another process already performed the action. Although according to the docs "os.unlink" doesn't throw an exception if the link doesn't exist, also not sure that such a protection is needed here at all.
os.unlink() will raise if the symlink does not exist. But we checked before that this is a link, so the link exist.
Of course it can fail if you write some code that will create and delete this link in a loop, and run it during setup, but in this case you deserve the results.
os.symlink(device, link_path)
chown(link_path)def remove_loop_device(link_path, backing_file):
2.17.2
sanlock-devel mailing list -- sanlock-devel@lists.fedorahosted.org To unsubscribe send an email to sanlock-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sanlock-devel@lists.fedorahoste...
sanlock-devel@lists.fedorahosted.org
-
Amit Bawer -
Nir Soffer