Download of subfolder contains parent folder
PhantomGamers opened this issue · comments
When using this website to download the folder AikoMidori/SteamSkins/tree/main/Metro/Metro-JS/, the resulting zip has the structure of Metro/Metro-JS/, whereas I would expect it to just have Metro-JS in the root.
Is this intended behavior or a bug? If this is intended behavior, could there be some way to change this with an argument passed?
I don’t remember this being an issue, are you on Windows?
This works correctly on iOS, the ZIP file seems to contain the raw contents of the folder, 5 files:
I don’t remember this being an issue, are you on Windows?
Yes, I'm on Windows 11 and the issue happens on both Firefox and Edge.
This works correctly on iOS, the ZIP file seems to contain the raw contents of the folder, 5 files:
* [download-directory.github.io/?url=https%3A%2F%2Fgithub.com%2Frefined-github%2Frefined-github%2Ftree%2Fmain%2Fsource%2Fgithub-events](https://download-directory.github.io/?url=https%3A%2F%2Fgithub.com%2Frefined-github%2Frefined-github%2Ftree%2Fmain%2Fsource%2Fgithub-events)
Yes, if I just put the folder link directly it has that behavior, but I do want the folder itself to be in the root of the zip file so I append / to the url.
For example:
https://download-directory.github.io/?url=https://github.com/AikoMidori/SteamSkins/tree/main/Metro produces a zip file that contains all of the files in the Metro folder in the root of the zip
https://download-directory.github.io/?url=https://github.com/AikoMidori/SteamSkins/tree/main/Metro/ produces a zip file that contains a Metro folder that then contains all of the files.
However https://download-directory.github.io/?url=https://github.com/AikoMidori/SteamSkins/tree/main/Metro/Metro-JS/ produces a zip file that contains Metro/Metro-JS
Also the same behavior applies to the repo you linked, with https://download-directory.github.io/?url=https%3A%2F%2Fgithub.com%2Frefined-github%2Frefined-github%2Ftree%2Fmain%2Fsource%2Fgithub-events/ containing source/github-events/*files*
Heh, this is undefined behavior. The fact that it behaves differently is a bug: both URLs point to the same resource and should produce the same output. In both cases the result should be the one I showed earlier.
Changing the zip’s structure is out of scope as the zip is just the current vessel to “download a directory” and may change at any time. See for example #94
In my opinion the current behavior generally makes sense, with / indicating that you want the folder itself being included, but I'll just fork this and fix that issue myself then if this feature is not in the scope of this project.