| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Keys database can hold multiple inode caches for a given key. One for
the annex object, and one for each pointer file, which may not be hard
linked to it.
Inode caches for a key are recorded when its content is added to the annex,
but only if it has known pointer files. This is to avoid the overhead of
maintaining the database when not needed.
When the smudge filter outputs a file's content, the inode cache is not
updated, because git's smudge interface doesn't let us write the file. So,
dropping will fall back to doing an expensive verification then. Ideally,
git's interface would be improved, and then the inode cache could be
updated then too.
|
| | |
|
| |
|
|
|
| |
Only loop when directory creation fails due to the directory existing
already.
|
| | |
|
| |
|
|
|
| |
Seems that Utility.SafeCommand loaded something that indirectly got that
instance loaded on unix, but not on Windows recently.
|
| |
|
|
| |
The two functions are identical.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
local git repo, and from a remote git repo.
Had everything available, just didn't combine the progress meter with the
other places progress is sent to update it. (And to a remote repo already
did show progress.)
Most special remotes should already display progress meters with -J,
same as without it. One exception to this is the web, since it relies on
wget/curl progress display without -J. Still todo..
|
| | |
|
| |
|
|
| |
Avoids problems if the program chdirs
|
| | |
|
| |
|
|
|
| |
Instead, just assume the daemon isn't running. Since the pid file locking
fails on such a filesystem, we know it's not running.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's a potential race, but it's detected and just results in the other
process failing to take the side lock, so possibly retrying one second
later on. The race window is quite narrow so the extra delay is minor.
Left the side lock files mode 666 because an interruption can leave a side
lock file created by another user for a shared repository. When this
happens, the non-owning user can't delete it (+t) but can still lock it,
and so the code falls back to acting as it did before this commit.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
And it closes the tmp file before this. I don't know if this will help
avoid lustre's craziness, but it can't hurt..
|
| | |
|
| |
|
|
|
|
| |
This is less portable, since currently sidelocks rely on /dev/shm.
But, I've seen crazy lustre inconsistencies that make me not trust the
link() method at all, so what can you do.
|
| | |
|
| |
|
|
|
|
|
|
| |
I have a strace taken on a lustre filesystem on which link() returned 0,
but didn't actually succeed, since the file already existed.
One of the linux man pages recommended using link followed by checking like
this. I was reading it yesterday, but cannot find it now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(not actually used anywhere yet)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
file locks
|
| | |
|
| |
|
|
| |
support that; avoid crashing on such invalid encoding.
|
| | |
|
| |
|
|
| |
available, which should be more portable.
|
| |
|
|
|
|
|
|
| |
Fixes a recent-ish build warning on about 64 bit vs non.
This is the method used by the disk-free-space library, and I tested it to
yield the same results on even 10 tb drives on OSX -- so it's getting 64
bit values.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Also, rename lockContent to lockContentExclusive
inAnnexSafe should perhaps be eliminated, and instead use
`lockContentShared inAnnex`. However, I'm waiting on that, as there are
only 2 call sites for inAnnexSafe and it's fiddly.
|
| | |
|
| | |
|
| |
|
|
| |
It's only necessary to open a file for write when taking an exclusive lock.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Solaris, using f_bsize provided a value that is apparently much larger
than the real block size. The solaris docs for statvfs say
f_bsize is the "preferred" file system block size, and I guess the
filesystem prefers larger blocks, but uses smaller ones or something.
The docs also say that f_frsize is the "fundamental" block size.
Switched to using f_frsize on Linux and kFreeBSD too, since I guess
f_bsize could in theory vary the same way there too. Assuming that Solaris
is not violating the posix spec, I guess the linux man page for statvfs
is not as well written and I misunderstood it.
|
| | |
| |
| |
| |
| |
| | |
This is the kind of annoying thing that makes me not want to use a library.
conduitManagerSettings was a perfectly fine name and could have been kept
forever.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since I want git-annex to keep building on debian stable, I need to still
support the old http-client, which required explicit calls to
closeManager, or use of withManager to get Managers to close at appropriate
times. This is not needed in the new version, and so they added a
deprecation warning. IMHO much too early, because look at the mess I had to
go through to avoid that deprecation warning while supporting both
versions..
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
it cannot parse.
"Host\n" is a valid line, and actually gets parsed ok, but this also holds
for other lines that it fails to parse for some reason.
|
| | | |
|
Joey Hess