On Sat, May 1, 2021 at 8:05 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > And in case of tarfs, the compression is handled by the store > > abstraction, which makes it transparent to the rest of the logic. > > Ah, ok. > And in the zip case?
As I understand it, zip is a different model that basically combines functionality of tar and gzip; you cannot just zip a blob, you need a file tree. So it's not relevant for compressing ar files. tarfs can be run with --bzip2 and --gzip options, but not with --zip. > > Hmm, but doesn't the page reading/writing implementation need to > > access the file size, atime/mtime, etc.? All of which may be changed > > concurrently. > > IIRC it isn't handled by the pager itself. Is it? I don't think pager (as in libpager) knows anything about atime/mtime and other filesystem-specific cruft. The pager knows the size; but the callbacks need to know the size too, to decide how much to read/write in case of the last page. (To quote the Linux manual for mmap: "For a file that is not a multiple of the page size, the remaining bytes in the partial page at the end of the mapping are zeroed when mapped, and modifications to that region are not written out to the file.") -- Sergey
