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(a)redhat.com> wrote:
On Fri, May 31, 2019 at 4:14 AM Nir Soffer <nirsof(a)gmail.com> wrote:
> From: Amit Bawer <abawer(a)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
>
>