-
Notifications
You must be signed in to change notification settings - Fork 92
Description
Describe the bug
There is logic in the download data sets methods that if a download fails, it deletes the file at the same destination.
I'm not really sure why this is the intended logic, because if a file already exists in the same destination (for example you are redownloading a file to get updates perhaps) and you get an error (let's say you've lost connection with the server), then the existing file will be deleted.
E.g.
zowe-cli/packages/zosfiles/src/methods/download/Download.ts
Lines 168 to 175 in 2451323
| } catch (error) { | |
| Logger.getAppLogger().error(error); | |
| if (destination != null) { | |
| IO.deleteFile(destination); | |
| } | |
| throw error; |
zowe-cli/packages/zosfiles/src/methods/download/Download.ts
Lines 281 to 289 in 2451323
| }).catch((err) => { | |
| downloadErrors.push(err); | |
| failedMembers.push(fileName); | |
| // Delete the file that could not be downloaded | |
| IO.deleteFile(join(baseDir, fileName + IO.normalizeExtension(extension))); | |
| // If we should fail fast, rethrow error | |
| if (options.failFast || options.failFast === undefined) { | |
| throw err; | |
| } |
Expected and actual results
If the API returns enough info to make it possible, then I think the intention is that it should delete partially downloaded files. That's what I'd expect anyway.
Describe your environment
On a branch of Zowe Explorer main (3.3.0 SNAPSHOT) which is using zos-files 8.24.1
Additional context
This undesired behaviour actually happened to me mid testing so it's not just a pre-emptive thing from reading the code.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status