Couldn't access file

[Dr0mus]

Currently trying to extract XC2 (Xenoblade chronicles 2), bf2.arh archive file. Whenever I try to run the command xenoblade_toolset.exe extract_arh "C:\Users\Dromu\Documents\romfs" it takes a second to create the folder structure of the archive, but then it spouts out the error [0x000026B4] Couldn't access file: C:/Users/Dromu/Documents/romfs/bdat/common.bdat. I also tried to extract bf3.arh from xenoblade chronicles 3 but that also lead to the same error [0x000027BC] Couldn't access file: C:/Users/Dromu/Documents/romfs/archives/bdat/btl.bdat. I used yuzu's dumpfs, I don't know if that's the correct way but found that when I google searched.

[PredatorCZ]

Have you figured it out? If not you can edit config file and change create-zip from false to true. It should be set as true by default. By the problem you describe, it seems like you don't have write permissions for that folder for whatever reason. Or you ran out of disk space. I haven't tested it on Windows OS, so it might be OS problem as well.

[Dr0mus]

I have tried the latest nightly release. Firstly I have tried to extract to extract the arh with create-zip set to true and I ran into the issue of the zip file being corrupted (?). Was using 7zip When I looked at the extracted folder structure and files, all of them had 0kb of size. Also when I ran the command (same as in the original post) it kept posting yellow text saying Skipped empty filename id: 20663 from 20663 to 21047. I then tried to set create-zip to false and it created the folder and file structure and it worked! I am assuming it worked was because whenever I extracted the zip file, it created all the files and the folder structure which then the program could write to. Whenever I ran the program with create-zip to false with the folders and files deleted from when I extracted the zip, I noticed that all of the files that were supposed to be files were instead folders I am assuming the program thinks what it is writing to is a file but when in reality it only creates folders.

[PredatorCZ]

Looks like I forgot how my own API works. Should be fixed in v0.4.64. As for zip file, idk, I'm having problems correctly verifying Zip64 formats (don't have much of a chance to get such big zip files). But I've tested newly generated zips in Ark and P7Zzip and both passed integrity tests. The skipped empty filename is normal. Sometimes, there are dangling files that are not linked to the main folder structure.

[Dr0mus]

Extracted .ard again and looked at the zip file and there are duplicates of every file. I also noticed that when I try to extract the first file, for example lets say the file labeled "1", it extracts perfectly and the extracted file has the data on the disk but whenever I extract file "2" 7zip says the data is unavailable. Assuming if the duplicated files are removed, it will fix the extraction process (?)

[PredatorCZ]

That's weird, I've tried numerous apps and there aren't any duplicates on my end. What version of 7zip you have?

[Dr0mus]

22.01 (2022-07-15) edit: I have updated but the duplicated files still appear

[PredatorCZ]

I was able to replicate it, it looks like problem in 7zip. I'm using version 16. I tried version 16 for windows as well and duplicate files disappeared.

EDIT: I've also tried V19, that works too. I tried to use V23, but it behaves even worse than V22.

Further edit: Should be fixed in v0.4.65

[Dr0mus]

Opened it with the windows explorer, it didn't have the duplicated files. ty for the support