← All ideas
  • Published 13 Sep 2019

File Archives As Directories (*.zip, *.rar etc.)

Proposal

My feature suggestion is that the File Browser be able to treat file archives (eg. *.zip ) as directories. This would allow users to perform CRUD operations on files within archives without needing to pack and unpack the contents outside of Blender.

There is technical precedent for something similar to this already, where *.blend can be treated as object/data "libraries" from which you are able to import things into your scene.

What if I just want to use the file archive as a file?

Treating file archives as files would be the default behaviour, as it is currently. To dive into an archive as a directory, the user could right-click on the archive file and select "Browse Archive".

What would file archive paths look like?

File paths for file archives would treat the file archive as a directory. For example:

/Users/blender/Archive.zip/foo/bar.png

This would reference a file foo/bar.png inside of /Users/blender/Archive.zip .

What about recursive file archives?

File archives can contain other file archives, and as such, should also be treated as directories.

This could slow things down by creating an I/O bottleneck. For example, if archive B is inside a deflated archive A, any CRUD operations on files in archive B necessarily requires the inflation of archive A.

Extensibility

Aside from the standard zip files, there are countless proprietary file archive types (eg. game file archives) that could benefit from this. Therefore, I propose an interface be provided for users to create their own add-ons for custom file archive types.

The user would need to provide a few key bits of functionality:

  • Registered file extension for the file archive type (eg. *.wad for Half-Life 1 WAD files)
  • Directory listing (file names, "stats" (last modified times etc.))
  • File read
  • File creation (optional)
  • File write (optional)
  • File deletion (optional)

If the user doesn't require or wish to provide write capabilities, they can specify that the file archive is read-only, and Blender can behave as though it is dealing with a read-only file/directory.

Side note: It may also be useful to provide a low-cost sanity check that the file archive is correctly formatted (eg. checking for a magic header).

Comments?

I'm throwing this idea out there to see if there's any obvious flaws or glaring technical roadblocks I might be overlooking. I did some poking around in the File Browser code yesterday, and it seems that while this would be a big change, nothing about this is technically infeasible.

I decided to write up this proposal because of my experience writing addons for importing assets from games with proprietary formats. One of the biggest headaches is dealing with these archives outside of Blender, keeping the files in the archive synched up with a working folder etc. Being able to completely streamline this process across a wide array of file archives would be a huge boon to many workflows, I'm sure.

Please let me know what you think. Thank you for your time.

clickbait.jpg

100%

Development Status: Open

Upvote 4 Downvote 0
cmbasnett
13 Sep 2019

2 Comments

Josephbburg

I like the idea of giving users the ability to extend the feature to access any arbitrary archive, but I don't think it's possible (or keeping with the GNU GPL spirit) to open proprietary formats with hooks to proprietary code. As long as you open the .wad or whatever with FOSS, it should be OK. Otherwise there will be legal loops to jump through.

cmbasnett Author

* @Josephbburg * Correct, though things like ZIP (the most common archive type) are an open format, so a custom implementation would be fine and wouldn't violate any licenses. I edited the post to exclude proprietary formats from the examples.

1