Fix FileToDatasetConverter picking up non-existing files

[imagejan]

It turns out that io.canOpen actually returns true for a file like blobs.gif even if it doesn't exist on the given path (see #434 (comment)). FileToDatasetConverter should really only be accepting requests where the file exists (or the name ends with .fake for the special case of the fake file format).

The tests are adjusted to be testing for unsupported formats as well as non-existing but theoretically supported files.

Closes #434.
Should also fix scijava/scijava-common#442.

[hinerm]

Thanks for this @imagejan!

I am getting concerned that we have parallel systems performing the same tasks, in the ConvertService and LocationService - maybe unfounded, but I want to sanity check ourselves here.

For example, if I open a .fake string (whether directly from a string or from a file named on disk) it goes through the TestImgLocationResolver and now that it's a Location it can unambiguously be opened as an ImgPlus and wrapped into a Dataset if desired.

This PR is necessary because of how script parameters are run through the ConvertService - is that correct (in summary)? But we're special-casing fake images, when that logic is already encapsulated in the TestImgLocationResolver.. right?

Looking at your explanation here, I am wondering why any of our formats claim support for a FileLocation that doesn't exist. Would it be reasonable if that was handled somewhere like in AbstractChecker instead of FileToDatasetConverter? That would also address io.canOpen, right?

[imagejan]

Thanks @hinerm for the information.

I didn't know enough about the details of Checker, and when looking at the source of io.canOpen, thought it would be easiest (and maybe safest) to do the check for file existence right here in the converter. And after fixing it, the tests would be failing for .fake so I added the special-casing.

But I agree with you that it would probably preferable to fix it in AbstractChecker or somewhere else upstream. It's just that I didn't know how to best do it, that's also why this issue remained known and open for so long.

[imagejan]

Now that I'm thinking of it: Checker is used in both opening and saving files, right? So checking for file existence in AbstractChecker will break file saving (where the destination usually doesn't exist yet). @hinerm @ctrueden do you have some better hint where the check should be made?

[hinerm]

Now that I'm thinking of it: Checker is used in both opening and saving files, right?

Ah good point. This is reason enough for me to just merge as-is 😄