-
Notifications
You must be signed in to change notification settings - Fork 302
shared windows paths are badly interpreted when opened on *nix #1786
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I couldn't reproduce this on my local network. I followed the following steps:
In fact for me it's the other way around; projects created from windows behave fine on Linux, but Linux projects present with the behaviour you described when opened on windows. The project URI is In contrast, Windows projects have file paths such as |
I'm a bit short on time, so i apologise for the short comment. However i feel like for you Windows->Linux worked because you mounted the SMB address to a local drive (i.e. |
I don't follow, I do not have a "Shared Network window in the file explorer" |
I am afraid i can't as I've been using my institute's services, and I'm not an expert when it comes to windows. Best i can do is study and try find guides to replicate this :/ |
Right, well I'll see if I can debug using the share I created, but if there's a way around it (mounting locally) then I'd suggest using that for the time being |
Note that if the images in the project aren’t changing, you can fix the paths once and have both
within the same directory, and just drag the correct one on to QuPath to open it. If you drag the entire project directory onto QuPath, then you will see a prompt asking you which to use. Both projects will work on the same data files, but of course anything stored only in the project file won’t be synced (e.g. if images are added or removed). There is described here in the docs, where it is proposed as a way to handle the use of shared drives. Even though this situation sounds a little different, I’d still suggest it as a workaround as we’re quite limited in the setups we can test against. |
Oh yes, thank you for reminding me! However the assumption that images in the project aren't changing is often valid, but not always, i am afraid... |
Before we begin...
Before submitting your bug report, please check the following:
Bug report
Describe the bug
This bug arises only on *nix systems when opening a QuPath project that was last opened on Windows and that has images on a shared network.
On windows, shared resources path follow the following convention:
When opening the project on linux, however, you are not prompted by QuPath that it can't find the associated images. Instead, you get an error when trying to opening an image:
java.io.FileNotFoundException
and
java.io.IOException
Interestingly, project
uri
is well escaped from Windows (i.e. it starts withfile:////
). It's the image serveruri
s that aren't (i.e. they start withfile://
) in.qpproj
files.Workaround
Open the
.qpproj
file and rename all occurrences offile://ServerComputerName
to anything else (e.g.file:////ServerComputerName
)To Repro duce
Steps to reproduce the behavior:
Expected behavior
I'd expect QP to warn that it can't find the images specified in the project, and later it suggests to specify a path where to search for them.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: