Hello all, In replying to someone having trouble with the BLAST+ tools, I found a new bug (and was reminded of an old bug I'd not yet reported) in the handling of composite datatypes without a primary file (e.g. BLAST databases). Consider the screenshot, where the history text for my BLAST database says "empty" (above the line saying "format: blastdbn") and the "full path" (highlighted) shown via the "information" icon points at an empty file, in this case: $ ls /mnt/galaxy/galaxy-dist/database/files/009/dataset_9085.dat -l -rw-r--r-- 1 galaxy galaxy 0 May 17 14:40 /mnt/galaxy/galaxy-dist/database/files/009/dataset_9085.dat The real data is here: $ ls /mnt/galaxy/galaxy-dist/database/files/009/dataset_9085_files/ blastdb.nhd blastdb.nhi blastdb.nhr blastdb.nin blastdb.nog blastdb.nsd blastdb.nsi blastdb.nsq I am guessing the code assumes a composite datatypes like HTML with a primary file, where it makes some sense to measure the size of the primary file (although this omits the child files like images for an HTML file) and use its location on disk. In the case of basic composite datatypes like BLAST databases, the "full path" should be the folder name, and the size should count all the child files within that folder (which is NOT empty). Looking at the code, $ grep "Full Path:" */* templates/show_params.mako: <tr><td>Full Path:</td><td>${hda.file_name | h}</td></tr> This suggests that the hda.file_name attribute might be assigned the folder name in this case? Or might that have repercussions? Thanks, Peter
participants (1)
-
Peter Cock