If you use fstream.Reader({ path: <path>, type: 'Directory' }) and tar to tar up a directory whose first entry is a non-writeable file, you can't untar it with tar. It works fine if you use fstream.Reader(<path>) instead. Here's a reproduction:
$ npm install
$ node index.js
... tars and untars example/ fine
$ node index.js bad
... EACCES on untar
The only difference when you add the bad argument is that it uses fstream.Reader({ path: <path>, type: 'Directory' }) instead of fstream.Reader(<path>).
I think there are two issues here:
The "bad" argument to fstream.Reader causes the outputted tarball to not contain an entry for the top-level example/ directory. I didn't dig into this too much, but it sort of looked like the reader was immediately emitting an entry for the top-level directory, but without any permissions or other properties. This entry was getting emitted before the pipe to the writer was set up, so it was being lost. If I paused all the streams until all the pipes were set up, the tarball would come out with an entry for the top-level directory but with permissions 0000.
When fstream.Writer (as part of untarring) makes the first entry in the tarball (example/f), it creates example/ with the same permissions as f. It seems to me that example/ should perhaps come out with default permissions if it doesn't have an entry for example/, not with the permissions of example/f.
When using fstream.Reader(<path>), the tarball comes out with an entry for the top-level directory with the correct permissions.
If you use
fstream.Reader({ path: <path>, type: 'Directory' })
andtar
to tar up a directory whose first entry is a non-writeable file, you can't untar it withtar
. It works fine if you usefstream.Reader(<path>)
instead. Here's a reproduction:https://github.com/estark37/fstream-eacces-bug
The only difference when you add the
bad
argument is that it usesfstream.Reader({ path: <path>, type: 'Directory' })
instead offstream.Reader(<path>)
.I think there are two issues here:
fstream.Reader
causes the outputted tarball to not contain an entry for the top-levelexample/
directory. I didn't dig into this too much, but it sort of looked like the reader was immediately emitting an entry for the top-level directory, but without any permissions or other properties. This entry was getting emitted before the pipe to the writer was set up, so it was being lost. If I paused all the streams until all the pipes were set up, the tarball would come out with an entry for the top-level directory but with permissions 0000.fstream.Writer
(as part of untarring) makes the first entry in the tarball (example/f
), it createsexample/
with the same permissions asf
. It seems to me thatexample/
should perhaps come out with default permissions if it doesn't have an entry forexample/
, not with the permissions ofexample/f
.When using
fstream.Reader(<path>)
, the tarball comes out with an entry for the top-level directory with the correct permissions.