Closed jkingsman closed 7 months ago
The .txt file should be complete.
Not sure why the cygwin64 zip program is failing.
Disk can always be specified as D: or /cygwin64/d -- either works when in a Linux command shell like BASH.
You either have to use only forward slashes or always double backslash with Cygwin64. The program is using only forward. Your examples seem to have mixed.
What type of slash is used depends on what command shell you are in and what program is interpreting the command line parameters (the shell, the program itself, etc). It is a real headache with WSL because you have to use DOS conventions for parameters except those passed to a Linux program. So you have to mix methods in one command line.
I will work to make the program detect the issue and fail more gracefully. If you leave the CombinedKit file there, it will be used to generate the other vendor files you request. Taking about 1 minute for each.
Ah, well, it appears then that the zip utility does not care for the forward slashes in the destination, at least. I was just showing the minimum viable resolution in my example; it's been a while since I've had to remember which cygwin utilities will make peace with different slashes or not haha.
Anyway, not a huge issue, just wanted to give a heads up that n=1 for the convention failing on the zip invocation.
I will definitely look into it further. Just to confirm, do you have the installation on D:/WGSExtractv4_alpha and the output directory (and maybe source data files) set to D:/ ?
What has me scratching my head is I develop on Windows and the Cygwin64 environment. And so test it first and most. Have likely generated the CombinedKit over a thousand times there. And never seen the issue. I have all the past releases installed on both Win11 and Win10. Both on C: and D: drives. (There is a bug in the FASTQC Java program when run on windows where if the data files are on a different drive than the Java installation, it bombs out. So one of my regression tests ;)
FYI, the only difference between Beta, Alpha and Dev is that specific term in the release.json file. It is used to select one of the many "latest-release" json files. Which defines the lectionary of 6 other packages and their versions. So v44.2 is the same in all tracks. Just Beta and Alpha tend to lag depending on how much testing has occurred.
And you are always welcome to apply your knowledge to fixing or expanding the features :) FYI, if you turn debug on, then all BASH scripts generated are kept in the temp folder. You can view, edit, run them again yourself. Just make sure to use the cygwin BASH and not the ancient one delivered with Windows.
Just as a follow-up, I took the ButtonCombinedKit.sh file from the temp/ folder and extracted the command: "C:/WGSE/Betav4.44p2/cygwin64/bin/zip.exe" -j "D:/DNA/WGS/Randy Harr/WGSEv4/60820188481027_CombinedKit.zip" "D:/DNA/WGS/Randy Harr/WGSEv4/60820188481027_CombinedKit.txt"
Running that in a Cygwin64 BASH shell on its own works just fine. I can see no issue except wondering if you ran out of disk space on D:/ when executing the final zip.exe command? I check for free disk space for major commands like BWA or SAMTOOLS SORT but not for simple items like this.
Note that it will try and run the zip program on the individual vendor files it creates as well. Did those work for you? Here is my entry from ButtonMicroarrayDNA.sh that zip's the vendor files: "C:/WGSE/Betav4.44p2/cygwin64/bin/zip.exe" -mj "D:/DNA/WGS/Randy Harr/WGSEv4/60820188481027_23andMe_V3.zip" "D:/DNA/WGS/Randy Harr/WGSEv4/60820188481027_23andMe_V3.txt"
Here is the failure message from the zip program you report which I am not familiar with: zip I/O error: No such file or directory zip error: Temporary file failure (D:/zismf8Vj)
I am guessing it is creating a temp file where the final file will be located. And simply renames that once finished. So maybe it had trouble creating the file there for some reason.
So sorry -- I would dig into this further but there's just been a family crisis and I'm leaving for emergency travel. I will come back to this when I'm able. Apologies for reporting and dashing off!
Howdy! Thanks so much for an amazing program.
I've replicated on both Beta and Alpha v4.44.2 on Win11.
I'm trying to run a Microarray-raw extraction, in Everything mode with no other output formats. My relevant CLI output:
The zip it's reaching for doesn't exist anywhere due to the creation failure, which happens due to a slash issue in the output parameter:
Works (backslash in target zip name):
Fails (forward slash in target zip name, as executed by script) -- temporary file error is a red herring:
However, I do get my output
NG1NUBUSQA.mm2.sortdup.bqsr_CombinedKit.txt
which looks 23aM-esque.I'm not super concerned with the error, but wanted to validate my understanding from looking through the python that the outputted .txt, on a failure at this stage, is complete/not subject to further processing (looks like this is dying on a cleanup operation). Basically, confirming that although there was an error in cleanup, this file is the last stage and suitable for cases where I want the full microarray.
Does that seem right?
Thanks for confirming!