[Next-Generation Sequencing Book]

Submit | Open tickets | Closed tickets

[ Ticket #1185 ] Need more robust way to recover if BIRCH download fails
Date:
08/13/13 21:09
Submitted by:
B_Fristensky 		Assigned to:
Alvare
Category:
Getbirch 		Priority:
7
Ticket group:
Bug 		Resolution:
Resolved
Summary:
Need more robust way to recover if BIRCH download fails
Original submission:
If a BIRCH download fails during an update, you are left with missing BIRCH directories, because getbirch refuses to try to install if a partial copy of BIRCH exists. This happens because the first thing we do before downloading is to run UNINSTALL-birch.py.

This would probably also be a problem if we were doing a new install.

We need to rethink how getbirch determines what to do if a previous install attempt has failed.
Please log in to add comments and receive followups via email.
Followups
Comment Date By
Several fixes:

1. Getbirch now runs UNINSTALL-birch within the download method, after downloading and before untarring.

2. UNINSTALL-birch.py now has a -d <dirname> option that is called to ensure that it finds the copy of BIRCH that needs to be deleted.

3. To make UNINSTALL-birch independent of whether or not the rest of BIRCH is present, code from various Python modules in birchlib have been hard-coded into UNINSTALL-birch.py, making it a standalone script.

4. If there is not a copy of UNINSTALL-birch.py, getbirch downloads a copy so it can do the uninstall.
08/25/13 17:03 B_Fristensky
Decision: Let's run UNINSTALL-birch AFTER the downloads are complete. The only advantage to running before is that it saves disk space, and we can usually assume that most systems today will have enough extra disk space.
08/17/13 15:23 B_Fristensky
Install: Don't need to worry about install. Getbirch gives the framework and bin files unique names each time a download is done. These are Java temporary files, meaning that JVM automatically deletes them when done. So a failed download during a new install should not leave behind a partial version of BIRCH.
08/17/13 13:59 B_Fristensky
No results for "Dependent on ticket"
No results for "Dependent on Task"
No other tickets are dependent on this ticket
Ticket change history
Field Old value Date By
status_id Open 08/25/13 17:03 B_Fristensky
resolution_id Not Resolved 08/25/13 17:03 B_Fristensky
close_date 12/31/69 19:00 08/25/13 17:03 B_Fristensky
status_id Pending 08/13/13 21:10 B_Fristensky
priority 5 08/13/13 21:10 B_Fristensky
assigned_to unset 08/13/13 21:10 B_Fristensky
resolution_id Unset 08/13/13 21:10 B_Fristensky

© 1998-2025 Scilico, LLC. All rights reserved.