dwifslpreproc: Unhandled Python exception

[Neurophysics-CFIN]

Describe the bug

Calling dwifslpreproc gives Unhandled Python exception on Ubuntu via wsl on Windows 10:

dwifslpreproc dwi_full_denoised_degibbs.mif dwi_full_denoised_degibbs_eddy.mif -rpe_pair -se_epi b0pair.mif

dwifslpreproc:
dwifslpreproc: Note that this script makes use of commands / algorithms that have relevant articles for citation; INCLUDING FROM EXTERNAL SOFTWARE PACKAGES. Please consult the help page (-help option) for more information.
dwifslpreproc:

dwifslpreproc: [ERROR] Unhandled Python exception:
dwifslpreproc: [ERROR]   PermissionError: [Errno 13] Permission denied: '/mnt/f/Dropbox/Projects/Collab/AAU/data-18-08-23/proc/mrtrix-tmp-96CkdQ.json'
dwifslpreproc: [ERROR] Traceback:
dwifslpreproc: [ERROR]   /home/sune/NYUdesigner/mrtrix3/bin/dwifslpreproc:101 (in execute())
dwifslpreproc: [ERROR]     image.check_3d_nonunity(path.from_user(app.ARGS.input, False))
dwifslpreproc: [ERROR]   /home/sune/NYUdesigner/mrtrix3/lib/mrtrix3/image.py:133 (in check_3d_nonunity())
dwifslpreproc: [ERROR]     image_in = Header(image_in)
dwifslpreproc: [ERROR]   /home/sune/NYUdesigner/mrtrix3/lib/mrtrix3/image.py:46 (in __init__())
dwifslpreproc: [ERROR]     os.remove(filename)

The file in questions has all rights set:

-rwxrwxrwx 1 sune sune 21559 Aug 29 09:37 /mnt/f/Dropbox/Projects/Collab/AAU/data-18-08-23/proc/mrtrix-tmp-96CkdQ.json

Perhaps the error is related to the existence of front slashes in the file names? If I comment out line 46 in image.py, it runs without error.

Platform/Environment/Version

Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

• MRtrix3 version (example: mrinfo -version) [ e.g. 3.0_RC3-309-g0074bc6c ]

= mrinfo 3.0.4-567-g598b0769 ==
64 bit release version, built Aug 17 2023, using Eigen 3.3.7
Author(s): J-Donald Tournier (d.tournier@brain.org.au) and Robert E. Smith (robert.smith@florey.edu.au)
Copyright (c) 2008-2023 the MRtrix3 contributors.

Python 3.8.10

Best,
Sune

[Lestropie]

Thanks for the report. That is indeed an interesting one.

I'm not sure that it can be the path separators given that the preceding open() call uses the very same filesystem path with no additional manipulation. To have that level of incompatibility in os.remove() would I thought have been identified and rectified.

One thing Windows is known for in this context is refusing to delete files with open file descriptors. Unfortunately I believe it does give a "permission denied" OS error message, which can be a red herring. So perhaps if the pseudo-network file system that WSL is using to mount the host is failing to release the file descriptor despite the open() call going out of scope, that would preclude a file delete.

I will hopefully know more once I recover my own Windows desktop from being incapable of proceeding to a blue screen of death. Rather than removing, you could replace with the following:

try:
  os.remove(filename)
except OSError:
  pass

I may well end up having to push that as a fix, but I'd rather identify what's going on first.

[Neurophysics-CFIN]

Hi Robert.

I can confirm that your suggestion works.

Sune