I spent my time implementing the extracting the DLCs methods this week. Since the DLCs were downloaded as .zip files. We needed a way to extract the files from the zip file.<\/p>\n
The process of extracting the contents was simple: use the existing method called However, there were some problems with the current The new file names are punycode encoded file names. The purpose of punycode encoding is to ensure compatibility with all operating systems by processing different symbols (like The problem in the current punycode encoding was that the file name we were initially getting from the zip file was a relative file path instead of just the file name (like lure\/protect.pdf and not protect.pdf). Indeed it should be a path; how else are we going to preserve the original location of the zip’s contents with multiple folder hierarchies? Punycode encoding this path name with the special symbol slash ( Once the zip file is downloaded and extracted, it should be deleted to free up the user’s storage. For deleting the zip file, a simple call to Apart from the extracting, there was also a bug in my session request code for starting a download session of DLC. Once the DLC was downloaded, this session was not automatically killed and remained in paused state. And I was getting the error callback called whenever I quit the ScummVM program. This was fixed by calling the session request’s close() method in the download file callback at the end of the stream (i.e., DLC is downloaded) to delete the request.<\/p>\n","protected":false},"excerpt":{"rendered":" I spent my time implementing the extracting the DLCs methods this week. Since the DLCs were downloaded as .zip files. We needed a way to extract the files from the zip file. The process of extracting the contents was simple: use the existing method called dumpArchive() after creating the new Archive object. You can read […]<\/p>\n","protected":false},"author":15,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-109","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/posts\/109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/comments?post=109"}],"version-history":[{"count":6,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/posts\/109\/revisions"}],"predecessor-version":[{"id":115,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/posts\/109\/revisions\/115"}],"wp:attachment":[{"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/media?parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/categories?post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/ankushdutt\/wp-json\/wp\/v2\/tags?post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}dumpArchive()<\/code> after creating the new Archive<\/code> object. You can read more about the ScummVM’s Archive<\/code> class on the doxygen documentation<\/a>. We already have a method called makeZipArchive()<\/code> that does the job of creating an archive object using the zip in the provided path.<\/p>\ndumpArchive()<\/code> method. All files extracted were getting renamed to something like xn--lureprotect.pdf-ua69e<\/code>. The original corresponding file is protect.pdf<\/code> of a game called Lure of the Temptress. This was an issue because ScummVM’s game detector could not automatically recognize these files with the new name. When adding a new game from the ScummVM’s GUI, we were presented with the could not find any game error.<\/p>\n\/<\/code>, :<\/code>, etc.) in filenames. If we were to remove the punycode encoding, certain special symbols in filenames might not be allowed\/supported on certain operating systems. For example, we could not name Echo I\/O:Room<\/code> in MacOS since it didn’t allow colon :<\/code> for naming a file\/folder as it used :<\/code> as a path separator.<\/p>\n\/<\/code>) prevented it from getting detected. We already have a class called Path<\/code>, which can contain string components of any file path. For example, the components of a path abc\/def\/g.h<\/code> are abc<\/code>, def<\/code>, g.h<\/code>. By using Path<\/code> instead of String<\/code>, we can differentiate between the \/<\/code>, the path separator, and \/<\/code> that appears in the file name. To get the Path<\/code>\u00a0for each file in the zip, I used the method that was recently created in this PR<\/a>. Also, the punycode encoding method for the path object was already implemented, which executed the original punycode encoding of string for all the path’s components.<\/p>\nunlink()<\/code> with the file’s path is sufficient, and the file will be deleted. This unlink()<\/code> is included in <unistd.h><\/code>, which is included in POSIX-supported operating systems. On Windows, we needed to call _unlink()<\/code> instead.<\/p>\n