-
Notifications
You must be signed in to change notification settings - Fork 192
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
🐛 Engine: Recover behavior for
upload_calculation
after refactor
In 6898ff4 the implementation of the processing of the `local_copy_list` in the `upload_calculation` method was changed. Originally, the files specified by the `local_copy_list` were first copied into the `SandboxFolder` before copying its contents to the working directory using the transport. The commit allowed the order in which the local and sandbox files were copied, so the local files were now no longer copied through the sandbox. Rather, they were copied to a temporary directory on disk, which was then copied over using the transport. The problem is that this changed the behaviour of `upload_calculation` in several ways: 1. if the sandbox contained the directory `folder` and the `local_copy_list` contained the items `(_, 'file', './folder/file')` this would work just fine in the original implementation as the `file` would be written to the `folder` on the remote folder. The current implementation, however, would write the file content to `folder/file` in a local temporary directory, and then iterate over the directories and copy them over. Essentially it would be doing: Transport.put('/tmpdir/folder', 'folder') but since `folder` would already exist on the remote working directory the local folder would be _nested_ and so the final path on the remote would be `/workingdir/folder/folder/file`. 2. if the sandbox contained the directory `folder` and the `local_copy_list` tries to copy a file to that folder via e.g. `(_, 'file', 'folder')`, this would raise an `IsADirectoryError` in the original implementation. Instead, the current implementation creates a file named `folder` with the contents of `file` and then copies this into the `folder` directory. 3. if the sandbox contained the directory `folder` and the `local_copy_list` tries to copy a local folder in a `FolderData` to that directory via e.g. `(_, 'folder', 'folder')`, this would simply copy the _contents_ of that directory to `folder` in the original implementation. The current implementation creates a nested `folder/folder` hierarchy. Although some of the new behaviour might be more intuitive and correspond closer to that of `remote_copy_list` (e.g. [3] above), changing it would be a backwards-incompatible change that could break existing plugins. Here, we adapt the `_copy_local_files` function to replicate the original behaviour of `upload_calculation`: 1. When copying a local directory, the contents of the temporary directory are copied to the remote using the `Transport.put` interface with `overwrite` set to `True`. 2. When copying a local directory, the parent directory is created on the remote, after which the single file is copied from the temporary directory to the remote. 3. In case the source type is `FileType.FILE` and the target is a directory, an `IsADirectoryError` is raised. 4. In case the source filename is specified and it is a directory that already exists on the remote, we avoid nested directories in the target path by setting the target filename to '.'. This means the contents of the node will be copied in the top level of the temporary directory, whose contents are then copied into the target directory. To verify that the behaviour is unchanged versus the original implementation, we add a large number of tests for various use cases of `upload_calculation` that have been run successfully against the latest release tag (v2.5.1). Co-Authored-By: Sebastiaan Huber <[email protected]>
- Loading branch information
Showing
2 changed files
with
318 additions
and
21 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters