I want to read metadata (file CRC32s) from the footer of a zip file that is stored on a (Google Drive) remote. One method I had some success with was mounting the remote, then just using a normal tool (7zip, this command: 7z l -slt file.zip) on the zip. However 7-zip gets stuck on Scanning the drive for archives: 0M Scan
for a few minutes (although not as many minutes that'd be needed to download the file), which is strange since surely only a few bytes of data need to be transferred and running this on a local file is instant.
Is this a bug, or is there some argument I need to pass to the rclone mount command, or is this just the wrong approach to reading this info from remote ZIPs?
yes, i agree.
tho sometimes the cache does make a difference with poor internet connect and super slow onedrive.
i have never seen that.
in the past, i have extracted files from .7z from a rclone mount.
so i tried just now to run your command, almost instant results
the .7z is 826MiB, 672 folders, 2318 files.
the file is hosted in wasabi, s3 rclone known for hot storage
so could be that:
--- your internet connection, is slow, high latency
--- onedrive is always very slow, including api calls.
--- how the .7z was compressed.
I tried the zip-backend branch, I also tried using mount with a simple python script that just gets the filenames and crc32s from the ZIP, but with both, there was still a long delay with both... zipcrcget.py.txt (464 Bytes)
Seems like using zipfile -l (which only lists filenames and sizes) on a mount is instant, but using zipfile -v (which lists more info, such as CRC32) has the same delay as the other methods.