ARTICLE AD BOX
I am looking for a reliable way to reconstruct a folder structure after a large Google Drive download. When downloading a high-volume directory (50GB+), Google Drive "chunks" the download into a sequential stream. Large files are delivered as standalone raw files, while smaller files are grouped into ZIP archives.
The resulting files in my ~/Downloads folder are interleaved by their part numbers:
DataPart.A-001.log (Raw file)
Archive-20260217T185712Z-002.zip (Internal structure: logs/folder_A/file.txt)
DataPart.B-003.log (Raw file)
Archive-20260217T185712Z-004.zip (Internal structure: logs/folder_B/file.txt)
The Problem: While the ZIP files preserve the internal directory hierarchy when extracted, the raw files (-001, -003) have lost their path metadata and sit in the root of the download folder. There is no manifest or README included to map these files back to their original subfolders.
It appears Google Drive performs a linear walk of the directory tree. It streams files until a size threshold is hit, then "cuts" the part.
If it hits a large file in a subfolder, it sends it as a raw part.
If it hits small files, it bundles them into a ZIP part.
The sequence numbers (001, 002, 003) reflect this chronological "walk" through the folders.
I prefer not to use sync tools (like rclone or Google Drive for Desktop) or the Google Drive API to keep the process simple and localized to the downloaded files.
I am looking for a solution (Bash or Python) that can "slot" the raw files into the subfolders defined by the ZIP files that immediately precede or follow them in the sequence.
This post seems to get at a similar, but simpler problem where there are only .zip files: Combine the split zip files downloading from Google Drive
Question: Has anyone developed a script to automate this "stitching" process based on the part numbers? Specifically, how can I programmatically identify which subfolder a raw file belongs to by using the directory context provided by the neighboring ZIP chunks?
