After uploading a zip file and trying to unarchive this file, I get the following error:
Diving a bit deeper, it looks like the current API expects the client to pass in the target directory in which the extracted files will be placed and upon receiving the request checks if that directory actually exists.
Looking at the request being sent out, an odd target directory seems to be passed to the API, after decoding the base64 I get the following: .\Create-generated-1 when trying to unarchive a file in the root folder called .\Create-generated.zip.
When I manually create this directory, the target directory requested by the client changes to .\Create-generated-2.
Personally, whenever I'm using a ZIP file, I'm usually trying to setup a modpack or restore from a backup, so I'd like the files inside the archive to be extracted inside the folder the archive is sitting in (./). Ofcourse having an option in the future to change the target folder sounds great, but the working directory would make for a sane default that would probably resolve this issue quite quick.
After uploading a zip file and trying to unarchive this file, I get the following error:![image](https://user-images.githubusercontent.com/7956579/222269160-34e874b6-3501-4653-9b5a-db58bc8465d0.png)
Diving a bit deeper, it looks like the current API expects the client to pass in the target directory in which the extracted files will be placed and upon receiving the request checks if that directory actually exists.
Looking at the request being sent out, an odd target directory seems to be passed to the API, after decoding the base64 I get the following:
.\Create-generated-1
when trying to unarchive a file in the root folder called.\Create-generated.zip
.When I manually create this directory, the target directory requested by the client changes to
.\Create-generated-2
.Personally, whenever I'm using a ZIP file, I'm usually trying to setup a modpack or restore from a backup, so I'd like the files inside the archive to be extracted inside the folder the archive is sitting in (
./
). Ofcourse having an option in the future to change the target folder sounds great, but the working directory would make for a sane default that would probably resolve this issue quite quick.