| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
was set to the empty string and the other set to some expression, this bug caused all files to be wanted, instead of only files matching the expression.
Avoid: MAny `MOr` otherexpression
Which matches anything.
|
| | |
| |
| |
| | |
transition
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
When gpg.program is configured, it's used to get the command to run for
gpg. Useful on systems that have only a gpg2 command or want to use it
instead of the gpg command.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It was failing at link time, some problem with terminatePID.
Re-implemented that to not use a C wrapper function, which cleared up the
problem. Removed old EvilLinker hack with must have been related to the
same problem.
Note that I have not tested this with older ghc's. In
4f59f9439687cccfb7aac6aca62dbe97038179bf I mention having tried this
approach before, and getting segfaults.. So, who knows. It seems to work
fine with ghc 7.10 at least.
|
| |
|
|
| |
It's the default, but this is a step toward changing that default later..
|
| | |
|
| |
|
|
| |
needed for "make fast" to work
|
| |
|
|
|
|
|
|
|
|
| |
This is mostly to be able to see how long a command took to run. Also exit
code may be useful.
Unofrtunately, I can't put the command name in there, because it's not
available at this point, and it would be a much larger change to wrap the
ProcessHandle data type to add that. However, it's generally pretty obvious
which process exited from context.
|
| |
|
|
|
|
|
|
| |
encoding
Since _encodeFilePath generates a String that doesn't use the filesystem
encoding, when this exception is caught, we know we already have such a
String, and can just return it as-is.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was caused by 88aeb849f620a13da47508045daae461a223c997
an Arbitrary String is not necessarily encoded using the filesystem
encoding, and in a non-utf8 locale, encodeBS throws an exception on such a
string. All I could think to do is limit test data to ascii.
This shouldn't be a problem in practice, because the all Strings in
git-annex that are not generated by Arbitrary should be loaded in a way
that does apply the filesystem encoding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
characters, when in a non-unicode locale.
Oh boy, not again. So, another place that the filesystem encoding needs to
be applied. Yay.
In passing, I changed decodeBS so if a NUL is embedded in the input, the
resulting FilePath doesn't get truncated at that NUL. This was needed to
make prop_b64_roundtrips pass, and on reviewing the callers of decodeBS, I
didn't see any where this wouldn't make sense. When a FilePath is used to
operate on the filesystem, it'll get truncated at a NUL anyway, whereas if
a String is being used for something else, it might conceivably have a NUL
in it, and we wouldn't want it to get truncated when going through
decodeBS.
(NB: There may be a speed impact from this change.)
|
| |
|
|
|
|
|
|
| |
using the cryptonite library.
While cryptohash has SHA3 support, it has not been updated for the final
version of the spec. Note that cryptonite has not been ported to all arches
that cryptohash builds on yet.
|
| |
|
|
|
|
|
|
|
| |
This fixes a reversion introduced by relative path changes back last winter.
The root cause is simplifyPath "../foo" was incorrectly yielding "foo".
absPathFrom seems quite horrible. Probably most things that use it should
use </> instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit f21bd84a8cc8f664106d2cb18fd38152d3372040.
|
Joey Hess
Simon Jakobi