4 ms·
Yes, it's expected for a general system utility like tar to handle such simultaneous file operations gracefully.
by newnewpdro 8y ago
Yes, it's expected for a general system utility like tar to handle such simultaneous file operations gracefully.
- hollerith 8y agoAgreed. OTOH, it is not a bug if the fact that tar is not instantaneous causes the tarball to contain combinations of files unlikely to occur during normal operation of the system. e.g., if a file is renamed while tar is running it is not a bug for the tarball to contain zero or two copies of that file.
- newnewpdro 8y agoIt is a bug for tar to enter an infinite loop writing an ever expanding file of trailing zeroes because the current file was truncated to a size smaller than its stat returned. It's basically a classic TOCTOU race, tar needs to honor the EOF returned from read() as authoritative. This is actually a very common trap for junior *nix programmers; treating stat() and a subsequent mmap() or read() loop as if they were atomic with regards to stat.st_size. The size returned by stat() can be used as an estimate, but otherwise can't be applied to subsequent operations.