compomics
TRFP still fails for symlinked input
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 get
2024-04-12 13:30:02 ERROR Unable to access the RAW file using the native Thermo library.
If I use a normal file it works.
And for mono 5.14.0.177-he1b5a44_1001 I get
Standard output: Running: mono /home/berntm/miniconda3/envs/mulled-v1-0cd30c5d6a5dfd6e1cdae92fa77519b67d60c5d07561a4b2ce73d269f19d2b55/bin/ThermoRawFileParser.exe -i=in/ginkgotoxin-ms-switching_raw.raw --output_file=output.mzML -f=2 -e
2024-04-12 13:22:02 INFO Started parsing in/ginkgotoxin-ms-switching_raw.raw
2024-04-12 13:22:02 ERROR An unexpected error occured (see below)
2024-04-12 13:22:02 ERROR System.TypeInitializationException: The type initializer for 'Mono.Unix.Native.Syscall' threw an exception. ---> System.DllNotFoundException: runtimes/linux-x64/libMono.Unix.so
at (wrapper managed-to-native) Mono.Unix.Native.Syscall.get_at_fdcwd()
at Mono.Unix.Native.Syscall..cctor () [0x0000a] in <7e182e4a9ebf470ba0164bbdc84457af>:0
--- End of inner exception stack trace ---
at Mono.Unix.UnixPath.TryReadLink (System.String path) [0x0000b] in <7e182e4a9ebf470ba0164bbdc84457af>:0
at Mono.Unix.UnixPath.ReadLink (System.String path) [0x00000] in <7e182e4a9ebf470ba0164bbdc84457af>:0
at ThermoRawFileParser.RawFileParser.ProcessFile (ThermoRawFileParser.ParseInput parseInput) [0x00078] in <3c141f2e2c4948d79a178bf4900cfc86>:0
at ThermoRawFileParser.RawFileParser.TryProcessFile (ThermoRawFileParser.ParseInput parseInput) [0x00002] in <3c141f2e2c4948d79a178bf4900cfc86>:0
2024-04-12 13:22:02 INFO Processing completed 1 errors, 0 warnings
Standard error: Process 'mono' did not finish successfully (exit code: ). Please check the log.
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?
Mono 6 and Windows .NET Framework
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.
Mono 5
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.