Downloading git-annex...
--2025-08-24 12:49:08--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64-ancient.tar.gz
Resolving downloads.kitenet.net (downloads.kitenet.net)... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2
Connecting to downloads.kitenet.net (downloads.kitenet.net)|66.228.36.95|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2025-08-24 12:49:09 ERROR 403: Forbidden.

The Download with the git-annex-install script fail, I guess because the build is failed. see: https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/

enableremote encryption changes: FAIL (0.73s)
./Test/Framework.hs:92:
initremote failed with unexpected exit code (transcript follows)
initremote baz
git-annex: There is no security benefit to using onlyencryptcreds=yes with encryption=shared
failed
initremote: 1 failed

It would be grate if you could fix that. Thanks in advance.

3x more allocations now than before. This is probably due to the switch to OsPath, which means extra copying from ByteString.

    Thu Aug 21 20:18 2025 Time and Allocation Profiling Report  (Final)

       git-annex +RTS -p -RTS find

    total time  =        0.99 secs   (989 ticks @ 1000 us, 1 processor)
    total alloc = 1,514,545,208 bytes  (excludes profiling overheads)

COST CENTRE                        MODULE                         SRC                                                 %time %alloc

keyFile                            Annex.Locations                Annex/Locations.hs:(790,1)-(806,44)                   7.1   12.9
>>=.\                              Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(148,9)-(149,44)    6.9    2.4
>>=.\.succ'                        Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:148:13-76           5.6    0.7
keyFile.esc                        Annex.Locations                Annex/Locations.hs:(796,9)-(801,32)                   5.3   10.7
ifM                                Utility.Monad                  Utility/Monad.hs:(62,1)-(64,44)                       5.1    8.7
ifM.\                              Utility.Monad                  Utility/Monad.hs:64:9-44                              3.5    8.6
hashUpdates.processBlocks          Crypto.Hash                    Crypto/Hash.hs:(103,5)-(112,76)                       3.1    0.3
inAnnex'.\                         Annex.Content.Presence         Annex/Content/Presence.hs:(53,61)-(68,31)             3.1    8.5
keyFile.anyneedesc                 Annex.Locations                Annex/Locations.hs:806:9-44                           3.1    1.0
seekFilteredKeys.exists            CmdLine.Seek                   CmdLine/Seek.hs:465:9-92                              2.8    0.4
fileKey                            Annex.Locations                Annex/Locations.hs:(814,1)-(824,41)                   2.1    1.0
keyPath                            Annex.Locations                Annex/Locations.hs:(834,1)-(836,23)                   1.8    5.9

This happens sometimes and will eventually get fixed when joey notices it. Currently the binary is only on his laptop apparently.

You can use an older version which is eventually available on archive.org:

[[!format bash """ yann in yann-desktop-nixos in …/OSX/current/10.15_Catalina on  master took 2s123ms 🐟 ❯ git co d8a7d5d54d24d17810f07c0756e7334e998650fe HEAD ist jetzt bei d8a7d5d54d publishing git-annex 10.20250630 10.20250606 yann in yann-desktop-nixos in …/OSX/current/10.15_Catalina on  HEAD (d8a7d5d) 🐟 ❯ git annex whereis whereis git-annex.dmg (1 copy) 5dc2ccd1-e534-4dae-8e8c-f31c8015e26e -- archive.org via S3

The following untrusted locations may also have copies: 00000000-0000-0000-0000-000000000001 -- web

web: http://archive.org/download/git-annex-builds/SHA256E-s28610967--7fc0dbf3f0a1f275a95730899327694b90dcd60c4ba8d8070a3efde44983a719.dmg ok """]]

So for example this link:

Hi there!

I'm learning how to use unlock, and I'm relatively new to git-annex.

I think I’ve understood the concept behind this feature, but I don’t get why, in the example, the git annex lock command is used after git annex add:

git annex unlock photo.jpg
gimp photo.jpg
git annex add photo.jpg
git annex lock photo.jpg   <------ This one
git commit -m "redeye removal"

Isn’t the file already locked by the git annex add ?

Thank you in advance.

If you exclude them from wanted or gitignore them before ever importing from the special remote, it won't delete them. But if you already imported a tree containing the files, and then exclude them, and then export a tree, git-annex will see that the old tree contained the file, and the new tree did not, and so will delete the file.

I'm getting acquainted with this special remote. I cannot praise it enough. It is brilliant.

This is my first cut git-annex-compute-stripexif:

[[!format bash """

!/bin/bash

set -e

if [ -z "$1" ]; then echo "Specify the input image file, followed by the output image file." >&2 echo "Example: foo.jpg foo.gif" >&2 exit 1 fi

echo REPRODUCIBLE echo "INPUT $1" read input

if [ -n "$input" ]; then tf=$(mktemp) cp "$input" "$tf" >&2 exiftool -overwrite_original -ALL= "$tf" >&2 outfile="SANSEXIF-"$(git-annex calckey "$tf") fi echo "OUTPUT $outfile" read output

cp -v "$tf" "$outfile" >&2 rm -v "$tf" >&2 """]]

Along the way, I've learnt that EXIF metadata isn't the only metadata stored in a jpeg, so the name is now a bit of a misnomer. Also, as it was more proof-of-concept, the target name and location is not well thought out, and there's no preservation of file extension. It's indicative for now.

The aim is to aid (only) in the identifying two copies of the same jpeg, where only the metadata has been changed (eg. either by adjustments I made by script eons ago, or by apps like Microsoft photoviewer where orientation changes were made via metadata). I say aid only, because it's not going to help if the image is resized, etc. and I understand that.

To that end, I do have some questions. The first is... is it wise (or possible) to try to set metadata on the source files whilst in the script? (since writing this, I have come to understand that the compute script is not run within the working directory, and the implication is that you're not meant to run any git-annex commands)

Obviously, the idea would be to tag the source file with the computed key. I have already verified that if two copies of a jpeg that differ only by metadata, the computed file and key will be the same.

But what I found is, if I don't have that option to set metadata, then respectfully, git-annex-findcomputed may have some deficiencies.

From what I can gather, git-annex-findcomputed will not list the subsequent input file that when added, computes it. Only the first one.

So trying to post process the computed files to perform the setting of metadata on the source files would likely not work.

Also, I was curious about what happens if the input file moves within the archive? I haven't tried... but from what I can see, you wouldn't be able to backtrack from the computed file, because you won't know the key of the input file, in turn to go searching for it (eg. git-annex-whereused).

Is my use case way off base as to why you should use the compute remote?

Hi,

seems the repordata folder is empty again and no release is published :(

Evgeni