In my mind this should work. buf_reader contains a reference to a ZipFile tied to the lifetime of Item. In newzip_file is borrowed from zip_archive and the compiler states that zip_archive is dropped at the end of new, but how can I tell the compiler that Item will own zip_archive meaning that the reference to zip_file will be alive for the same scope (as it's tied to the lifetime of Item)?
That is, your new function is saying that the item must not outlive the filename you've given it. If you want an Item that owns its ZipFile, you need to construct an Item<'static>, or an item that is not borrowing anything.
Another problem you probably have is that your ZipFile appears to borrow from the ZipArchive, which means Item is a self-borrowing struct, and that's not allowed in safe Rust. (If Item is moved, your buf_reader could become invalid.)
An Item<'a> is necesarrily only valid within the scope of some object with lifetime 'a that it borrows from. If you're borrowing from a ZipArchive, you need to pass a reference to the ZipArchive into Item::new when you construct the item.
But how can this be explained? Don't structs own their fields? If structs do own the fields, then the newly formed struct Item should have the ownership of the zip_archive field and the zip_archive variable declared in new function should no longer be the owner and the value shouldn't be dropped.
So, if I have a ZipArchive with a single ZipFile in it is it even possible to create a struct that iterates over the ZipFile? This is basically what I would like to do, maybe I am approaching the problem in the wrong way.