| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
feed has repeatedly had a problems for at least 1 day.
|
| | |
|
| |
|
|
|
| |
The latter is harder for me to remember, but avoids build failures in code
used by the configure program.
|
| |
|
|
| |
duplication
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
maximum filename length limit.
Started with a problem when running addurl on a really long url,
because the whole url is munged into the filename. Ended up doing
a fairly extensive review for places where filenames could get too large,
although it's hard to say I'm not missed any..
Backend.Url had a 128 character limit, which is fine when the limit is 255,
but not if it's a lot shorter on some systems. So check the pathconf()
limit. Note that this could result in fromUrl creating different keys
for the same url, if run on systems with different limits. I don't see
this is likely to cause any problems. That can already happen when using
addurl --fast, or if the content of an url changes.
Both Command.AddUrl and Backend.Url assumed that urls don't contain a
lot of multi-byte unicode, and would fail to truncate an url that did
properly.
A few places use a filename as the template to make a temp file.
While that's nice in that the temp file name can be easily related back to
the original filename, it could lead to `git annex add` failing to add a
filename that was at or close to the maximum length.
Note that in Command.Add.lockdown, the template is still derived from the
filename, just with enough space left to turn it into a temp file.
This is an important optimisation, because the assistant may lock down
a bunch of files all at once, and using the same template for all of them
would cause openTempFile to iterate through the same set of names,
looking for an unused temp file. I'm not very happy with the relatedTemplate
hack, but it avoids that slowdown.
Backend.WORM does not limit the filename stored in the key.
I have not tried to change that; so git annex add will fail on really long
filenames when using the WORM backend. It seems better to preserve the
invariant that a WORM key always contains the complete filename, since
the filename is the only unique material in the key, other than mtime and
size. Since nobody has complained about add failing (I think I saw it
once?) on WORM, probably it's ok, or nobody but me uses it.
There may be compatability problems if using git annex addurl --fast
or the WORM backend on a system with the 255 limit and then trying to use
that repo in a system with a smaller limit. I have not tried to deal with
those.
This commit was sponsored by Alexander Brem. Thanks!
|
| | |
|
| |
|
|
| |
Returned the possibly non-unique file
|
| |
|
|
|
|
|
| |
When there's no extension, don't use "none", but "".
When there is an extension, it starts with a dot, so don't put a redundant
dot in the default format.
|
| | |
|
| |
|
|
|
|
| |
filesystem encoding to the rescue once more!
IIRC this was the main bug in hpodder.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
unless you use the --force.
This was the last place in git-annex that could remove data referred to by
the git history, without being forced.
Like drop, dropunused checks remotes, and honors the global annex.numcopies
setting. (However, .gitattributes settings cannot apply to unused files.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In direct mode, it's best to whenever possible not move direct mode files
out of the way, and so I made unannex avoid touching the direct mode file at
all.
That actually turns out to be easy, because in direct mode, unlike indirect
mode, the pre-commit hook won't get confused if the unannexed file later
gets added back by git add. So there's no need to commit the unannex right
away; it can be staged for the user to commit later. This also means that
unannex in direct mode is a lot faster than in indirect mode!
Another subtle bit is the bookkeeping that is done when unannexing a direct
mode file. The inode cache needs to be removed so that when uninit runs
getKeysPresent, it doesn't see the cache and think the key is still
present and crash when it's not.
This commit is sponsored by Douglas Butts. Thanks!
|
| |
|
|
| |
the work tree
|
| |
|
|
| |
that old versions of files and deleted files are not deleted. Print a message with some suggested actions.
|
| | |
|
| |
|
|
| |
not correspond to any unused key.
|
| |
|
|
| |
the urls's path.
|
| | |
|
| |
|
|
| |
useful to put in a post-receive hook to make a repository automatically update its working copy when git annex sync or the assistant sync with it.
|
| |
|
|
| |
last run of git annex unused. Supported by fsck, get, move, copy.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
A common failure mode for direct mode has been for files to end up still
stored in indirect mode. While I hope that doesn't happen anymore, fsck
should deal with it.
|
| |
|
|
| |
On old systems, it may need to be run as root.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It's causing some problem on windows, see
http://git-annex.branchable.com/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/#comment-45df9748bba687d95e3c96b3877ea925
And only affected WORM backend, and for one release well over a year ago,
so could well be bitrotted.
|
| |
|
|
|
| |
This is because people continually whine about it. Seemingly not aware
that data generally cannot be deleted from git anyway.
|
| |
|
|
| |
branch on such a remote, instead of to synced/master. This makes it easier to clone from a bare git remote that has been populated with git annex sync or by the assistant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
adding them.
This write permission frobbing is very appropriate in indirect mode,
since annexed objects are stored as immutably as can be managed. But not
in direct mode, where files should be able to be modified at any time.
There are already sufficient guards that there's no need to prevent a file
being written to while it's being ingested, in direct mode. The inode cache
will detect (most) types of modifications, and the add will fail. Then a
re-add should be done. The assistant should get another inotify change
event, and automatically add the new version of the file.
|
| |
|
|
| |
when a new repo is made.
|
| |
|
|
| |
do not support hard links, but do support symlinks and other POSIX filesystem features.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This reverts commit 733a90bbd382683fa788aa6949f0fac11ba6504b.
The stderr fd is also trashed after `am` fails to open the web browser.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Avoid using dupped stderr, since
http://git-annex.branchable.com/bugs/warning_-_WebApp_crashed:___60__file_descriptor_15__62__:_hPutStr:_illegal_operation___40__handle_is_closed__41___on_Android/#comment-a24c73803fb10bd35afdc10d50e071c8
seems to involve that handle not being dupped originally, or perhaps
getting closed when the web browser is started on Android.
Using the dupped stdout is known to work before starting the web browser,
so it should work after -- unless perhaps starting it closes both handles.
In any case, there's no real need to write to stderr here.
|
| |
|
|
| |
Android devices that cannot auto-open the webapp on start.
|
| |
|
|
| |
Still need to git rm the old file so git accepts the merge is resolved.
|
| |
|
|
|
| |
588a981e17461643b67f9a372703b9e0896b6e17's fix caused it to try to stage a
symlink in .git/annex/tmp, oops
|
| |
|
|
|
|
|
| |
Ie, when there'a a conflicted merge we may get foo.variant-xxxx
created in a merge. If a second merge conflict occurs on that new file,
it was not falling back to putting in the whole key (which should stop
the merge conflicts happening for good, but is ugly).
|
| | |
|
Joey Hess