The pieces are almost all there:

• you can create an IO descriptor for an in-memory file with the :ram option for :file.open/2
• you can pass an IO descriptor to :erl_tar.open/2

so you might think this would work:

{:ok, fd} = :file.open("", [:read, :write, :ram])
{:ok, tar_desc} = :erl_tar.open({:file, fd}, [:write])

but this fails with an argument error:

** (FunctionClauseError) no function clause matching in :erl_tar.open1/4    
    
    The following arguments were given to :erl_tar.open1/4:
    
        # 1
        {:file, {:file_descriptor, :ram_file, #Port<0.7>}}
    
        # 2
        :write
    
        # 3
        [:raw]
    
        # 4
        []
    
    (stdlib 3.15.2) erl_tar.erl:324: :erl_tar.open1/4

FWIW, you are almost certainly going to get better performance with doing file-based operations against something like tmpfs (versus bending a ram_file to your will); depending on how many times ram_file needs to resize its internal binary it could get very expensive…

I would simply use tmpfs as mentioned earlier, you can mount it pretty much anywhere, it will give good IO performance and won’t require patching Erlang (and then running on your own build for a while, while it gets to the released version).

Zip files would work, I don’t know for tar… Erlang has a zip package readily available:

 :zip.create(file_list, [{:cwd, path}, :memory])

See the docs. I see there is a tar module as well.

Thanks, i’ll look into it and see if i can submit a patch to get around this.