Unexpected behavior when reading from an already consumed Entry

[klieth]

I got caught in a really weird bug earlier that ended up being entirely my fault, but it led to me thinking a little bit about the behavior of this library. Here's effectively what happened to me (total pseudocode, but it gets the idea across):

// load an archive
let mut archive = Archive::new(/* some reader */);
// iterate through the entires
archive.entries().unwrap().for_each(|e| /* do something */);
// a while later in the code, after forgetting that I iterated them already....
archive.entries().unwrap().map(|e| /* read with e.read_to_string(&mut result) */)

All I got in return from the final line was a list of empty Strings. Which made total sense--of course you can't read from that if you've already passed the data. However, it seems that the library could have said something in that case. Would it be possible to maybe return some sort of "already consumed" error if the data isn't available? Is there something else to be done that could make this more clear?

[alexcrichton]

Seems reasonable to me! If EOF has been reached with one iterator I'd also expect it to return errors from the other iterators (or at most an empty iterator)

[klieth]

In my specific case, I didn't actually have two separate iterators--I'd collected one into a Vec, then used it later in a loop where I thought it was still an un-consumed Entries iterator.

[alexcrichton]

Ah true yeah, that's a known caveat for this library which should be mentioned in the documentation but is an unfortunate side effect :(

[NightRa]

@klieth #160 / #166 should allow you to collect the entries to a Vec if really necessary.
Though you should iterate sequentially with Archive::entries to not have the entries' data stored in memory.