Open bernt-matthias opened 7 months ago
Hi @bernt-matthias,
How do you get the release of TRFP?
I tried with a clean conda environment (only mono=6.12.0.90 and the latest release downloaded from Github) and it works fine.
I could reproduce your error if I delete {trfp_parent_folder}/runtimes/linux-x64/libMono.Unix.so
(this file is shipped with the TRFP and is a part of platform-dependent symlink resolver). Could you, please, check that this file is present and/or accessible when you deploy TRFP?
I install via conda.
I also had troubles to reproduce. The point seems to be that the extension of the link target matters. A symlink test.raw -> LINK_TARGET.raw
seems to work, but test.raw -> LINK_TARGET.dat
seems not to work.
I looked a bit further into it.
I can confirm that mono 5.14 raises an error when processing symlinked files, although the dll is in place. I will need to investigate further, but maybe the solution is to require mono >=6
.
It looks like vendor libraries require .raw
(case insensitive) extension to open the file - if the link target does not have it, it won't work. The extension of the link is not important, since TRFP resolves a link to its target and feeds the target to the vendor library, i.e. file.raw -> file.data
will fail, but file.data -> file.rAw
will work fine.
I am afraid, there isn't much I can do about it. You can try to open an issue with https://github.com/thermofisherlsms/RawFileReader to remove this restriction.
Similarly, when having a directory as an input, TRFP will only try to open the files/links with the case-insensitive .raw
extension and ignore all other files. I prefer to keep it this way since it is less confusing than raising errors for each non-raw file.
What would happen if you feed the link (with the .raw
) extension to the vendor library?
The vendor library cannot process links directly (that was the initial issue #108). After the fix, TRFP checks if the provided path is a link, resolves its target (using WinAPI on Windows and Mono.Unix library on other platforms), and feeds the target path to the vendor library.
The vendor library can process symlinks directly. After the fix, Mono.Unix raises System.DllNotFoundException: runtimes/linux-x64/libMono.Unix.so
, although the DLL is there.
Just noticed that 1.4.3 still fails for input that is symlinked:
With
mono
6.12.0.90-h780b84a_0 (from conda-forge) I getIf I use a normal file it works.
And for
mono
5.14.0.177-he1b5a44_1001 I get