Skip to content
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

Updating unpublished file needs fallback #191

Open
bpoldrack opened this issue Mar 6, 2023 · 1 comment
Open

Updating unpublished file needs fallback #191

bpoldrack opened this issue Mar 6, 2023 · 1 comment
Milestone

Comments

@bpoldrack
Copy link
Member

On JülichDATA trying to replace an unpublished file leads to an error.
This is an issue even in the most simple case, bc we need to push after a create-sibling, which implies replacing the repository files.

In this case, we'd need to remove the file and re-upload instead of using the replace endpoint.

Here is a snippet I have that used to fix _upload_file for this with an additional conditional when checking the response:

        elif response.status_code == 400 and \
                response.json()['status'] == "ERROR" and \
                "You cannot replace an unpublished file" in \
                response.json()['message']:
            # This happens on JülichDATA if we try to replace an unpublished
            # file. The message suggests to remote + upload instead.
            self._remove_file(key, remote_file)
            response = self.api.upload_datafile(identifier=self.doi,
                                                filename=local_file,
                                                json_str=datafile.json())
@bpoldrack
Copy link
Member Author

@mih : We talked about how replace is only relevant for export mode, but I am once again not clear about datalad-annex remote helper. Those keys need replacement, I think. Note, that this is no difference from annex' POV with the current implementation, since it's transfer_store that detects the need for replacement here. If this fails, I think annex can't come up with its own workaround, b/c it can't tell that remove+transfer_store would work. So, this is different from renameexport.

@mih mih added this to the 1.1 release milestone Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants