@GrahamcOfBorg eval

Just for reference, here is a discussion on --delay-directory-restore from Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1206020

Just to summarise what I've learned from the previous comment and further perusal of the man pages.

1. --delay-directory-restore may cause high memory usage for large tarbals (many files/directories, not physical size) because the meta-data of all files is retained in memory so the restore can happen once unpacking complete.

2. The default behaviour of tar is good enough to work for a lot of files, but not all, particularly when directories in the archive are read-only or don't have their execute bit set (on a related note, this PR may resolve issue fetchzip doesn't like tarballs containing read-only directories #15527, but I haven't tried it).

   • By default tar assumes the files in an archive are ordered, and can therefore restore directory metadata once all the contents of a directory have been unpacked. In this case, tar will succeed even when directories are read-only. However, the chmod +x on directories is still required, otherwise the "make sources writable" step of the unpack phase will fail.

   • The second case is when files in an archive are not ordered; for example, a directory is unpacked, it's metadata restored, then tar encounters another file later in the archive belonging to the previous directory. In this case, --delay-directory-restore is required to delay permission restoration so the latter file can be added. Without the delayed restore, tar fails.

3. As far as I can tell, tar does not provide a means of modifying the contents of an archive before unpacking. This answer (https://unix.stackexchange.com/a/125487) provides a couple of suggestions. Mounting the archive as a filesystem is one way to modify permissions before unpacking. Presumably that incurs a lot of overhead, especially if a compressed archive is modified.

For reference, the same issue isaacs/node-tar#7

@Ericson2314 @matthewbauer @infinisil Any feedback on this change? I've been bit by this edge case and I think it'd be great if nixpkgs could handle these types of broken tar files.

@woehr It appears that the --delay-directory-restore option exists there because that mode should not be the default. Yet this PR makes it enabled by default and unconditionally. Even if it fixes your issue, it will invite breakage for someone else (perhaps somebody working with large tarballs). I don't think anybody wants that. So have you considered options that don't require modifying stdenv? In your derivation you could set TAR_OPTIONS = "--delay-directory-restore";. If that doesn't work, one could always make a derivation to wrap around fetchurl to implement a custom tar unpacker or have this logic put in overridden unpackPhase of your derivation.

@Mic92 Closed by accident?