git-annex-remote-rclone icon indicating copy to clipboard operation
git-annex-remote-rclone copied to clipboard

homebrew package: checkpresentkey fails for MS One drive

Open tdietel opened this issue 3 years ago • 3 comments
trafficstars

I am using git annex on a Mac with an rclone special remote on a MS One drive.

After not accessing the remote for a while, I noticed that I was no longer able to verify keys stored on this remote. I managed to track this down to a change of the output of rclone size, which on my system is:

$ rclone size one:annex/xyz/ca4/2c7/GPGHMACSHA1--60252740cbb2197ac145441b1b4e9bee2106056c
Total objects: 1 (1)
Total size: 11.777 GiB (12645937942 Byte)

The additional '(1)' for the total objects seems to confuse git-annex-remote-rclone v0.6 that was installed by homebrew. When I changed the grep regex to check for a valid resonse in line 200, I managed to make it work. I noticed that the equivalent expression in line 219 of the version on GitHub is different and probably does not suffer from this.

The problem seems to be that the homebrew formula uses the latest release package v0.6, which still has the bug. Would it be possible to create a new release with a bugfix? I will also file a bug report on homebrew.

tdietel avatar Jul 04 '22 06:07 tdietel

I can report that the same problem happens with rclone v1.59.0 on MacOS for me using Google Drive backend.

Currently, git-annex-remote-rclone tries to figure out whether a remote file exists by running rclone size and then trying to parse what is supposed to be human readable output, and it seems that the standard format of this has changed in a way that breaks the regex as described above by @tdietel . The --json option to rclone size could be used to perhaps provide for more reliably grep-able output.

Alternately, the developer of rclone suggests a different approach for testing if a file exists, i.e., by using

rclone lsf remote:path-to-file

and then confirming that the intended path is in the output. The same post also discusses a more efficient approach using rc, which I imagine could be used extensively throughout git-annex-remote-rclone but would likely be a much bigger job.

Either way, however, in order to get homebrew to use a fixed version, I believe we need to have a new release so that the formula can be updated to point at a new tarball; as far as I know it's not possible for homebrew to just track e.g., the master branch of a repo. That could be as simple as @DanielDent just making a new release based on the master, or just cherry-picking https://github.com/DanielDent/git-annex-remote-rclone/commit/75d24b7 (which I believe has the critical fix), or doing a more careful fix as described above and then making a new release.

dankessler avatar Jul 27 '22 18:07 dankessler

Just to make sure, by "Currently" you mean in a released 0.4 version of git-annex-remote-rclone and not current master (v0.4-38-gc287ee5), and that the issue is already addressed in master, and we just need a new release of git-annex-remote-rclone. Correct?

edit: correction that current release is 0.6 and just fell afoul of lightweight non-annotated tags being used for releases (damn github releases practice ;)) . current master is v0.6-17-gc287ee5

yarikoptic avatar Jul 27 '22 20:07 yarikoptic

Correct; by currently I mean in release 0.6

dankessler avatar Jul 27 '22 21:07 dankessler