This encodes flag information into the tar stream using
ReadFileFlagsToTarHeader and decodes with WriteFileFlagsFromTarHeader.
To support applying diffs to trees with flags, this adds logic to
reset immutable flags during the UnpackLayer process. To support
immutable directories, we also need to defer setting flags on
directories until after all modifications to the directory contents.
Fortunately, something similar is already in place for setting
directory modify times.
Signed-off-by: Doug Rabson <dfr@rabson.org>
Note: the Flags method of system.StatT always returns zero on
non-FreeBSD platforms so this should have no functional change for those
platforms.
Signed-off-by: Doug Rabson <dfr@rabson.org>
This adds platform-specific entry points to encode and decode file
flags. These are exported so that they can be used in buildah/copier. A
function which can be used to optionally reset the immutable flag on a
file or directory is also added and this will be used when applying
layer changes to trees with immutable files or directories.
These new entry points are implemented for FreeBSD and are noop stubs on
other platforms. The chflags approach could be used on darwin and other
BSD-derived platforms if needed.
On FreeBSD, file flag information is encoded for import/export using the
PAX SCHILY.fflags option. This is compatible with bsdtar (see
https://github.com/libarchive/libarchive). Reading the code for
libarchive, it also has support for encoding/decoding Linux file flags
so this seems like a good reference.
Signed-off-by: Doug Rabson <dfr@rabson.org>
Note: these are likely to be identical on other BSDs, including darwin,
but I'm keeping this for just FreeBSD to start with.
Signed-off-by: Doug Rabson <dfr@rabson.org>
Check for errors from command Wait() methods. Not sure how this
inconsistency even landed in the first version of this test.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Don't immediately unlock the layer store after locking it.
Luckily it only matters for additional stores.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Don't create "mounts" or "tmp" subdirectories under the graph root at
startup, since we ended up not using them.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
If we ever check the last-writer of a lock file and get back a zero
value, don't only check if subsequent last-writer values match its first
zero bytes, which is always true, as a test to see if the last-writer
value has remained unchanged.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
.. to be closer to the lock / load set of methods.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
They are now only used in the constructors, so use a variant
of startReading/startWriting instead. This code path is not
performance-critical, so let's share as much code as possible
to ensure consistency in locking.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is done implicitly by all writers already.
Also fix the documentation not to point at an explicit Touch(),
which is not actually necessary.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Exposing the internals of the lock is not necessary, and exposes
too many implementation details.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This integrates ReloadIfChanged, and makes it clearer that the responsibility
for maintaining locking details is with the layerStore; we can change it
in a single place.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This integrates ReloadIfChanged, and makes it clearer that the responsibility
for maintaining locking details is with the layerStore; we can change it
in a single place.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to be closer to the lock / load set of methods.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
They are now only used in the constructors, so use a variant
of startReading/startWriting instead. This code path is not
performance-critical, so let's share as much code as possible
to ensure consistency in locking.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is done implicitly by all writers already.
Also fix the documentation not to point at an explicit Touch(),
which is not actually necessary.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Exposing the internals of the lock is not necessary, and exposes
too many implementation details.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... for a bit of extra safety. That requires us to be a bit
more explicit in one of the users.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This integrates ReloadIfChanged, and makes it clearer that the responsibility
for maintaining locking details is with the imageStore; we can change it
in a single place.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This integrates ReloadIfChanged, and makes it clearer that the responsibility
for maintaining locking details is with the imageStore; we can change it
in a single place.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to be closer to the lock / load set of methods.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
They are now only used in the constructor, so use a variant
of startWriting instead. This code path is not performance-critical,
so let's share as much code as possible to ensure consistency
in locking.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is done implicitly by all writers already.
Also fix the documentation not to point at an explicit Touch(),
which is not actually necessary.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Doug Rabson