Closed mgree closed 1 month ago
TODO requested:
hs
currently relies on the fact that commiting does not remove files from the upperdir. So we need a way to have commit using cp
instead of mv
.Other points come up during review/discussion:
Question:
In the code we have
size_t tgt_len = ent->fts_statp->st_size + 1;
if (tgt_len == 0) { // apparently fancy FS can lie?
tgt_len = PATH_MAX;
}
I guess the point here is that for the strange cases where st_size being -1 (which we have not observed?), this clause is there to make the "realloc
with doubling sizes" later always start from a positive number?
* Although abusing a little of UB, `hs` currently relies on the fact that commiting does not remove files from the upperdir. So we need a way to have commit using `cp` instead of `mv`.
try-commit -c
will use cp
instead of mv
. I deliberately did not surface this behavior in try
.
Along the way, I changed try-summary
and try-commit
to take the sandbox as its argument, not the upperdir, which it finds itself. This feels like a nicer interface (and gives us flexibility to rename things later).
Other points come up during review/discussion:
* We have not encountered situations where xattr "trusted.overlay.whiteout" (or "user.overlay.whiteout") is used to mark deletion, but we have code for this. * We are not handling [redirect_dir](https://docs.kernel.org/filesystems/overlayfs.html#redirect-dir). * Regarding "trusted.overlay.opaque", due to the fact that we set userattr in [try's overlay options](https://github.com/binpash/try/blob/af013b518cad69389d150ff8be998f8ae2a78d56/try#L142), we don't have to deal with them.
Recorded these facts in utils/README.md
.
Question:
In the code we have
size_t tgt_len = ent->fts_statp->st_size + 1; if (tgt_len == 0) { // apparently fancy FS can lie? tgt_len = PATH_MAX; }
I guess the point here is that for the strange cases where st_size being -1 (which we have not observed?), this clause is there to make the "
realloc
with doubling sizes" later always start from a positive number?
Added a comment: procfs
(and possible other weird FS types) reports st_size
of 0 on lstat of symbolic links. :upside_down_face:
When everything passes CI, I'll merge. Next stop is #166!
Question: In the code we have
size_t tgt_len = ent->fts_statp->st_size + 1; if (tgt_len == 0) { // apparently fancy FS can lie? tgt_len = PATH_MAX; }
I guess the point here is that for the strange cases where st_size being -1 (which we have not observed?), this clause is there to make the "
realloc
with doubling sizes" later always start from a positive number?Added a comment:
procfs
(and possible other weird FS types) reportsst_size
of 0 on lstat of symbolic links. 🙃Not consequential at all but I have to ask: since
st_size == 0
=>tgt_len == 1
, this clause doesn't handle the case wherest_size
is 0 per se?
Ah, good catch. Fixed now. (Have you used GH's code review process? There's a whole thing where you "start a review" and group comments and can comment on lines.)
Attempting a drop-in replacement for the core logic of our
summary()
andcommit()
functions. Closes #126 and #159.TODO
shell script output in try-summary.cthis is easy to do but not necessary now; left #165USING
debug intry
sleep
intry-commit.c
writewill do this in another PR, this is too big (and we have workable tests for it for now)make -C utils install
targetTRYCASE
linter