Recent comments posted to this site:

Hi,

I followed these instructions but was unable to get git-annex to install on my Synology running Linux Anvil 4.4.59+ #24922 SMP PREEMPT Fri May 10 02:49:58 CST 2019 x86_64 GNU/Linux synology_denverton_1618+

Seems to be an issue regarding locale settings. The default locales are LANG=/usr/lib/locale/en_US LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL=en_US.utf8

The exception thats thrown is rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed. ./runshell: line 135: 27709 Aborted (core dumped) rm -rf "$localecache" 2>&1 rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed. ./runshell: line 135: 27716 Aborted (core dumped) rm -rf "$localecache" 2>&1 ./runshell: line 181: 27719 Aborted (core dumped) cmp "$LOCPATH/buildid" "$base/buildid" > /dev/null 2>&1 rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed. ./runshell: line 181: 27722 Aborted (core dumped) rm -rf "$LOCPATH"

any ideas how to fix?

Comment by se394 Tue Jul 30 13:54:43 2019

I've finally taken the time to learn git-annex and am extraordinarily impressed by its usefulness and documentation.

I'm currently using git-annex as part of a scientific workflow, wherein I use git to track my analysis source code and LaTeX reports, and git-annex to handle large binary files (typically input data). git annex sync is really handy for making sure my git-annex branch propagates between my remotes, and it's hard to beat the usefulness of git annex sync --content now that I've wrapped my head around standard groups. However, I'd prefer if there was a flag (or configurable option) to suppress git annex sync from pushing/pulling whatever branch currently happens to be checked out. I'm a pretty thoughtful committer and want more control over where my code branches (e.g., master) get pushed around. I saw the --no-pull and no-push options for git annex sync, but it seems that this suppresses all push/pull behavior, and thus git annex sync --no-push --no-pull will not sync up my special git-annex branch. Is there an option or workflow that accomplishes what I'm looking for?

TLDR I want a way to tell git annex sync to leave my master (or whatever currently checked out branch is) alone (no pushing/pulling), but otherwise behave normally (e.g., git annex sync will just push/pull my special git-annex-branch around, or git annex sync --content will push/pull the special git-annex branch, and also move content around as it makes sense). Apologies if this is already possible, but I haven't been able to figure it out.

Comment by Dan Tue Jul 30 13:54:43 2019

@Dan, there's an open todo about that, http://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/

Please followup there if the suggested new option would work for you.

Comment by joey Tue Jul 30 13:54:43 2019
I've also missed this functionality. One use is to sync the metadata.
Comment by Ilya_Shlyakhter Tue Jul 30 13:54:43 2019

Building on Windows gives this error:

[[!format sh """ Extracting ghc-8.6.5.tar

Everything is Ok

Size: 1773445120 Compressed: 280280296 Extracting ghc-8.6.5.tar... Extracted total of 9780 files from ghc-8.6.5.tar C:\Users\ilya\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.5-tmp6568\ghc-8.6.5: renamePath:MoveFileEx "C:\Users\ilya\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.5-tmp6568\ghc-8.6.5\" "C:\Users\ilya\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.5\": permission denied (Access is denied.)

"""]]

Running Git Bash with Administrator privileges does not seem to help. Anyone else run into this / know how to fix it? Thanks!

Comment by Ilya_Shlyakhter Tue Jul 30 13:54:43 2019
comment 17 360caa8972c2daa94044cc95188306e9
[[!comment Error: unsupported page format sh]]
Wed Jul 17 14:19:14 2019

On debian buster, copying to or from tahoe seems to alway cause an attempt to start a new tahoe process, even if one is already running, resulting in error messages like this on second or subsequent attempts:

copy P5273249.JPG STARTING '/home/jk/.tahoe-git-annex/3677c81a-5cd0-4817-9ad3-a7c29b74a7b7'
starting node in '/home/jk/.tahoe-git-annex/3677c81a-5cd0-4817-9ad3-a7c29b74a7b7'
Another twistd server is running, PID 20860

This could either be a previously started instance of your application or a
different application entirely. To start a new one, either run it in some other
directory, or use the --pidfile and --logfile parameters to avoid clashes.

Not a massive problem as everything seems to work.

Comment by jk Mon Jul 8 16:46:36 2019

Joey, I feel like I have asked it before, but can't quickly search it up, so asking again (sorry if repeating). By

To attach metadata to a particular path, rather than a particular key, use .gitattributes .

you meant attaching some other metadata, not really "git-annex" metadata, right? Or there is a way to specify metadata key=value pairs to be attached to annexed files, e.g. smth like

*_scans.json annex.metadata=(distribution-restrictions=sensitive)

?

Comment by yarikoptic Thu May 30 20:14:14 2019

"When versioning is not enabled, this risks data loss" -- maybe, add an option to always import before exporting? I don't want to enable versioning since that permanently loses the chance of dropping any objects (even if they're stored elsewhere).

Also, versioning on S3 buckets can be suspended/resumed; not sure if git-annex uses current bucket versioning state or the remote configuration.

Comment by Ilya_Shlyakhter Thu May 30 20:14:14 2019