Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
necessary because existing code assumes that the references graph is
acyclic.
|
|
|
|
through the build hook.
|
|
|
|
unreachable paths. This matters when using --max-freed etc.:
unreachable paths could become reachable again, so it's nicer to
keep them if there is "real" garbage to be deleted. Also, don't use
readDirectory() but read the Nix store and delete invalid paths in
parallel. This reduces GC latency on very large Nix stores.
|
|
|
|
|
|
It doesn't detect indirect references
|
|
There is probably a more efficient way to do this.
|
|
|
|
|
|
stream it's now necessary for the daemon to process the entire
sequence of exported paths, rather than letting the client do it.
|
|
(way fewer roundtrips) by allowing the client to send data in bigger
chunks.
* Some refactoring.
|
|
* Buffer the HashSink. This speeds up hashing a bit because it
prevents lots of calls to the hash update functions (e.g. nix-hash
went from 9.3s to 8.7s of user time on the closure of my
/var/run/current-system).
|
|
system calls / context switches when dumping a NAR and in the worker
protocol.
|
|
|
|
rather than complain about them.
|
|
daemon (which is an error), print a nicer error message than
"Connection reset by peer" or "broken pipe".
* In the daemon, log errors that occur during request parameter
processing.
|
|
* Say "fetch" instead of "substitute".
|
|
‘nix-store --export’.
* Add a Perl module that provides the functionality of
‘nix-copy-closure --to’. This is used by build-remote.pl so it no
longer needs to start a separate nix-copy-closure process. Also, it
uses the Perl API to do the export, so it doesn't need to start a
separate nix-store process either. As a result, nix-copy-closure
and build-remote.pl should no longer fail on very large closures due
to an "Argument list too long" error. (Note that having very many
dependencies in a single derivation can still fail because the
environment can become too large. Can't be helped though.)
|
|
libstore so that the Perl bindings can use it as well. It's vital
that the Perl bindings use the configuration file, because otherwise
nix-copy-closure will fail with a ‘database locked’ message if the
value of ‘use-sqlite-wal’ is changed from the default.
|
|
|
|
intermittent problems are gone by now. WAL mode is preferrable
because it does way fewer fsyncs.
|
|
derivation paths
This required adding a queryOutputDerivationNames function in the store API
|
|
causing a deadlock.
|
|
This should also fix:
nix-instantiate: ./../boost/shared_ptr.hpp:254: T* boost::shared_ptr<T>::operator->() const [with T = nix::StoreAPI]: Assertion `px != 0' failed.
which was caused by hashDerivationModulo() calling the ‘store’
object (during store upgrades) before openStore() assigned it.
|
|
derivations added to the store by clients have "correct" output
paths (meaning that the output paths are computed by hashing the
derivation according to a certain algorithm). This means that a
malicious user could craft a special .drv file to build *any*
desired path in the store with any desired contents (so long as the
path doesn't already exist). Then the attacker just needs to wait
for a victim to come along and install the compromised path.
For instance, if Alice (the attacker) knows that the latest Firefox
derivation in Nixpkgs produces the path
/nix/store/1a5nyfd4ajxbyy97r1fslhgrv70gj8a7-firefox-5.0.1
then (provided this path doesn't already exist) she can craft a .drv
file that creates that path (i.e., has it as one of its outputs),
add it to the store using "nix-store --add", and build it with
"nix-store -r". So the fake .drv could write a Trojan to the
Firefox path. Then, if user Bob (the victim) comes along and does
$ nix-env -i firefox
$ firefox
he executes the Trojan injected by Alice.
The fix is to have the Nix daemon verify that derivation outputs are
correct (in addValidPath()). This required some refactoring to move
the hash computation code to libstore.
|
|
|
|
character. (Nix/216)
|
|
|
|
daemon.
|
|
registerValidPaths() now handles busy errors and registerValidPath()
is simply a wrapper around it.
|
|
failure. The build hook can use this to distinguish between
transient and permanent failures on the remote side.
|
|
|
|
|
|
|
|
while checking the contents, since this operation can take a very
long time to finish. Also, fill in missing narSize fields in the DB
while doing this.
|
|
even with a very long busy timeout, because SQLITE_BUSY is also
returned to resolve deadlocks. This should get rid of random
"database is locked" errors. This is kind of hard to test though.
* Fix a horrible bug in deleteFromStore(): deletePathWrapped() should
be called after committing the transaction, not before, because the
commit might not succeed.
|
|
will approximately require.
|
|
|
|
|
|
size of the NAR serialisation of the path, i.e., `nix-store --dump
PATH'). This is useful for Hydra.
|
|
|
|
race with other processes that add new referrers to a path,
resulting in the garbage collector crashing with "foreign key
constraint failed". (Nix/4)
* Make --gc --print-dead etc. interruptible.
|
|
because it defines _FILE_OFFSET_BITS. Without this, on
OpenSolaris the system headers define it to be 32, and then
the 32-bit stat() ends up being called with a 64-bit "struct
stat", or vice versa.
This also ensures that we get 64-bit file sizes everywhere.
* Remove the redundant call to stat() in parseExprFromFile().
The file cannot be a symlink because that's the exit condition
of the loop before.
|
|
differs from the desired mode. There is an open SQLite ticket
`Executing "PRAGMA journal_mode" may delete journal file while it is
in use.'
|
|
set.
* In the build hook, print a trace message to allow Hydra to pick up
the name of the remote machine used for the build.
|
|
* If a path has disappeared, check its referrers first, and don't try
to invalidate paths that have valid referrers. Otherwise we get a
foreign key constraint violation.
* Read the whole Nix store directory instead of statting each valid
path, which is slower.
* Acquire the global GC lock.
|