New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"rucio download --no-subdir" behavior is different from its documentation #4323
Comments
Do we want to implement the documented behavior; or to fix documentation ? |
I think pilot expects this behaviour, so again, asking @PalNilsson :-) |
I implemented the other in #3737 and I missed the cli documentation, probably because it was marked a "bug". I am expecting the files to be overwritten, if they differ. |
So we want to overwrite files if they differ; but skip them if their checksum is correct ? |
that's my understanding, yes. CC: @bari12 |
Seems logical to me. It is probably worth also doing the same thing in the case when "--no-subdir" is not set. To have a consistent behavior. If file present but checksum different : redownload. If checksum correct, don't do anything. |
Yes, consistent behaviour would be good here I think. |
…#4323 Also update the "no-subdir" option documentation. In the past, rucio was changing its behavior of overwriting existing files depending on the 'no-subdir' option. If this option was set, local files were always overwritten. If the option was not set, the files were always let intact. This was counter-intuitive and was fixed in a recent commit as being a bug. Leaving an incorrect documentation. The discussion in the linked issue suggested that it will be the most intuitive to check the checksum of existing files. If their checksum is correct: leave them intact, but overwrite files in case of a miss-match.
…#4323 Also update the "no-subdir" option documentation. In the past, rucio was changing its behavior of overwriting existing files depending on the 'no-subdir' option. If this option was set, local files were always overwritten. If the option was not set, the files were always let intact. This was counter-intuitive and was fixed in a recent commit as being a bug. Leaving an incorrect documentation. The discussion in the linked issue suggested that it will be the most intuitive to check the checksum of existing files. If their checksum is correct: leave them intact, but overwrite files in case of a miss-match.
…#4323 Also update the "no-subdir" option documentation. In the past, rucio was changing its behavior of overwriting existing files depending on the 'no-subdir' option. If this option was set, local files were always overwritten. If the option was not set, the files were always let intact. This was counter-intuitive and was fixed in a recent commit as being a bug. Leaving an incorrect documentation. The discussion in the linked issue suggested that it will be the most intuitive to check the checksum of existing files. If their checksum is correct: leave them intact, but overwrite files in case of a miss-match.
…_redownload Clients: re-download existing files if checksum is wrong. Fixes #4323
Also update the "no-subdir" option documentation. In the past, rucio was changing its behavior of overwriting existing files depending on the 'no-subdir' option. If this option was set, local files were always overwritten. If the option was not set, the files were always let intact. This was counter-intuitive and was fixed in a recent commit as being a bug. Leaving an incorrect documentation. The discussion in the linked issue suggested that it will be the most intuitive to check the checksum of existing files. If their checksum is correct: leave them intact, but overwrite files in case of a miss-match.
Motivation
Rucio documentation for file download states that the "--no-subdir" will overwrite files if they exist in the destination folder.
However, the files are not overwitten, as shown by the following example :
Modification
Either the documentation must be updated to note that existing files will not be overwritten, or the files must be overwritten.
The text was updated successfully, but these errors were encountered: