Mark H Weaver <m...@netris.org> skribis: > Also of note: So far, all known instances of this problem have occurred > while transferring a large directory, as opposed to a tarball. > > We have several packages with source tarballs _much_ larger than these > problematic source checkouts, and which are updated more much > frequently, and yet I've *never* seen an instance of this problem while > exporting a plain file to a build slave. For example, the upstream > IceCat and Firefox ESR tarballs are ~270 megabytes compressed, whereas > 'font-google-material-design-icons-3.0.1' source is only ~176 megabytes > _uncompressed_. > > I have no explanation for why the superficial form of the store item > should matter here, but maybe it's a clue. I know that plain > non-executable files in the store are handled somewhat differently in > the Nix model than directories or executable files, the latter > associated with the word "recursive", and requiring an additional layer > of encoding for purposes of serialization, but I'm not sufficiently > familiar with the details or relevant code. > > Ludovic, can you think of a reason why the file/directory distinction > could be relevant to this issue?
No, I can’t see why it could make a difference. Ludo’.
