Joey Hess [Tue, 30 Aug 2022 19:20:04 +0000 (15:20 -0400)]
optimise linker in linux standalone tarballs
Trick the linker into not doing unncessary work searching for optimised
libraries that are not present, by symlinking the directories where
optimised libs would be to the main lib dir.
This reduces the ENOENT of git-annex init by about 1/2. The linker always
finds the files where it looks first time now. I have not looked at what
the wall clock speedup might be, it's probably rather small.
If a x86-64-v5 comes to be, the list will need to be extended. And there
may be other directories used on some machines that I have missed. Not done
for arm64 yet, or any uncommon architectures.
Joey Hess [Mon, 29 Aug 2022 19:21:00 +0000 (15:21 -0400)]
move assistant and webapp build-depends into main build-depends
For some reason, cabal 3.4.1.0 builds w/o the assistant and webapp,
even when the flag is explicitly turned on. Moving the build-depends from
inside the if flag section to the main build-depends somehow fixes this.
Since the webapp build deps are thus always available, there is no reason
not to build the webapp when building the assistant. So, got rid of the
webapp build flag. Kept the assistant build flag for now, since building
without it does at least still speed up the build.
Joey Hess [Fri, 19 Aug 2022 17:31:16 +0000 (13:31 -0400)]
import: Avoid following symbolic links inside directories being imported
Too big a footgun.
This does not prevent attackers who can write to the directory being
imported from racing the check. But they can cause anything to be imported
anyway, so would be limited to getting the legacy import to follow into a
directory they do not write to, and move files out of it into the annex.
(The directory special remote does not have that problem since it does not
move files.)
Joey Hess [Wed, 17 Aug 2022 17:07:14 +0000 (13:07 -0400)]
init: probe if sqlite works
Help the user get annex.dbdir configured when their filesystem is not
one that sqlite works on.
The change in Database.Handle makes an error from sqlite not be ignored
besides being displayed, which it was before. I can't see any reason
git-annex would want to ignore these errors.
I chose to use the fsck database rather than the keys database because
opening the keys database populates it, and see commit b3c4579c7907147a496bdf2c73b42238d8b239d6.
The placement of the call to checkSqliteWorks inside checkInitializeAllowed
avoids annex.uuid getting set before it's called.
Joey Hess [Mon, 15 Aug 2022 18:25:13 +0000 (14:25 -0400)]
correct documentation, keyid= only works once
keyid+= can be used to add additional key ids later.
I wonder if this broke with changes to remote configs? But I think it's
always been a map, and so only one keyid can be stored and later ones
overwrite earlier ones.
Joey Hess [Mon, 15 Aug 2022 16:22:01 +0000 (12:22 -0400)]
make it easier to use curl for unusual url schemes
Use curl when annex.security.allowed-url-schemes includes an url scheme not
supported by git-annex internally, as long as
annex.security.allowed-ip-addresses is configured to allow using curl.
I've verified that all the sqlite databases get stored in annex.dbdir
and are created successfully. If annex.dbdir does not exist, it will be
created; its parent directory must already exist though.
Joey Hess [Fri, 12 Aug 2022 16:45:46 +0000 (12:45 -0400)]
improve createDirectoryUnder to allow alternate top directories
This should not change the behavior of it, unless there are multiple top
directories, and then it should behave the same as if there was a single
top directory that was actually above the directory to be created.
Joey Hess [Thu, 11 Aug 2022 20:57:44 +0000 (16:57 -0400)]
add annex.dbdir (WIP)
WIP: This is mostly complete, but there is a problem: createDirectoryUnder
throws an error when annex.dbdir is set to outside the git repo.
annex.dbdir is a workaround for filesystems where sqlite does not work,
due to eg, the filesystem not properly supporting locking.
It's intended to be set before initializing the repository. Changing it
in an existing repository can be done, but would be the same as making a
new repository and moving all the annexed objects into it. While the
databases get recreated from the git-annex branch in that situation, any
information that is in the databases but not stored in the branch gets
lost. It may be that no information ever gets stored in the databases
that cannot be reconstructed from the branch, but I have not verified
that.
projects / git-annex.git / log