You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I spotted a bug in the xml wrapper for the busco tool in galaxy.
The bug causes a run to finish successfully but will only report empty files (or to be exact the correct output files are not copied back to the correct folders leaving the original empty stub files).
It seems that when the auto-detect lineage option is used there are additional directories created in the working directory of galaxy which make the condition to copy the output files fail and thus no files are copied, leaving the empty ones in place.
the code that is causing this behavior is the following: if [ -f "/scratch/galaxy/job_working_directory/004/4214/working/busco_galaxy/run_"*"/short_summary.txt" -a -f "/scratch/galaxy/files/006/dataset_6598.dat" ] ; then cp "/scratch/galaxy/job_working_directory/004/4214/working/busco_galaxy/run_"*"/short_summary.txt" "/scratch/galaxy/files/006/dataset_6598.dat" ; fi;
which can be found at the near end of the galaxy_???.sh (in the working-directory) file that is generated to run the tool in galaxy.
If there are multiple /run_*/ , the file check (-f) will fail because several matches are provided/found .
This is apparently the case when using the auto-detect option AND a lineage is detected different from 'eukaryote' or 'bacteria' ( so a more specific one) because then both the 'run_eukaryote' or 'run_bacteria' directory is presented (as a link to a deeper directory) as well as the more specific lineage directory (eg. run_entrobacteriales) as a plain directory.
Our current "fix" for this is to delete all link directories (before the output is processed through galaxy itself) but as you can understand this is not the correct solution ;)
I believe the reported issue here will likely also explain the following reported issues #6132 and #6200 .
The text was updated successfully, but these errors were encountered:
lsterck
changed the title
Bug in xml wrapper fro busco (causing emtpy output files, without any warnings/errors)
Bug in xml wrapper for busco (causing emtpy output files, without any warnings/errors)
Jan 8, 2025
Hi,
I spotted a bug in the xml wrapper for the busco tool in galaxy.
The bug causes a run to finish successfully but will only report empty files (or to be exact the correct output files are not copied back to the correct folders leaving the original empty stub files).
It seems that when the auto-detect lineage option is used there are additional directories created in the working directory of galaxy which make the condition to copy the output files fail and thus no files are copied, leaving the empty ones in place.
the code that is causing this behavior is the following:
if [ -f "/scratch/galaxy/job_working_directory/004/4214/working/busco_galaxy/run_"*"/short_summary.txt" -a -f "/scratch/galaxy/files/006/dataset_6598.dat" ] ; then cp "/scratch/galaxy/job_working_directory/004/4214/working/busco_galaxy/run_"*"/short_summary.txt" "/scratch/galaxy/files/006/dataset_6598.dat" ; fi;
which can be found at the near end of the galaxy_???.sh (in the working-directory) file that is generated to run the tool in galaxy.
If there are multiple /run_*/ , the file check (-f) will fail because several matches are provided/found .
This is apparently the case when using the auto-detect option AND a lineage is detected different from 'eukaryote' or 'bacteria' ( so a more specific one) because then both the 'run_eukaryote' or 'run_bacteria' directory is presented (as a link to a deeper directory) as well as the more specific lineage directory (eg. run_entrobacteriales) as a plain directory.
Our current "fix" for this is to delete all link directories (before the output is processed through galaxy itself) but as you can understand this is not the correct solution ;)
I believe the reported issue here will likely also explain the following reported issues #6132 and #6200 .
The text was updated successfully, but these errors were encountered: