[directory permissions] tar screwed on windows ?

[gkathan]

hej,
I am using gulp-tar within a auto-deploy build chain for an express application, and it works fine when using it on linux machines => unfortunately i also have to make it run on windows boxes:

• when i create a tarball on my windows box via:
  .....
  return gulp.src(_src)
  .pipe(tar(PACKAGE+'.tar'))
  .pipe(gzip())
  .pipe(gulp.dest(DIST));
• it creates a fine PACKAGE.tar.gz file
• when i ship/scp this to the prudction (linux) server and run the deploy script there
  ....
  tar -zxvf PACKAGE.tar.gz
• it starts to unpack but fails with "..Cannot open: Permission denied.."
• which roots from the fact that all directories are also set with 644 permission instead of 755 !

any advice ?
greetings from vienna/austria
gerold.

[sindresorhus]

@ctalkington Thoughts? This modules just passes the file paths too archiver and doesn't add any directories, but rather depend on implicit directory creation.

[gkathan]

I tried to pass some options to the tar() function....

.pipe(tar(PACKAGE+'.tar'),{"mode":0755})
.pipe(gzip())
.pipe(gulp.dest(DIST));

but without success...

[ctalkington]

i havent had any other reports of issue with tar permissions. for the most part archiver wraps tar-stream and since your module is using append a lot of the newer file stat logic doesn't come into play on the archiver side.

all the logic archiver runs on it comes from this block
https://github.com/archiverjs/node-archiver/blob/master/lib/core.js#L193

[gkathan]

just nm idea - is maybe in this codeblock the problem ?

• it just looks for a "normal" unix style slash "/"
• but it windows path is a backslash "" isn't it ?

...
if (data.name.slice(-1) === '/') {
isDir = true;
data.type = 'directory';
} else if (isDir) {
data.name += '/';
}
...

[ctalkington]

don't think thats the issue; sanitizePath is called before that line and converts slashes.
https://github.com/archiverjs/node-archiver/blob/master/lib/util/index.js#L93

this module also does some logic
https://github.com/sindresorhus/gulp-tar/blob/master/index.js#L27

it might be good to provide a sample repo to recreate and the tar produced, luckily tar is easier to read than zip.

[sindresorhus]

it might be good to provide a sample repo to recreate and the tar produced, luckily tar is easier to read than zip.

@gkathan ⬆️

[dadouf]

I'm afraid I have the same problem: after tar is pushed, can't untar it on the server because Cannot open: Permission denied.

[sindresorhus]

@dadouf ⬇️

it might be good to provide a sample repo to recreate and the tar produced, luckily tar is easier to read than zip.

[xsbchen]

according to https://github.com/archiverjs/node-archiver/blob/master/lib/core.js#L204
so, try this:

return gulp.src(_src)
    .pipe(tar(PACKAGE+'.tar', {mode: null}))
    .pipe(gzip())
    .pipe(gulp.dest(DIST));

[ghost]

We experienced the same permissions problem on our project at work.
We build on windows and deploy on Linux.
The solution provied by @obingo to set {mode: null} works. We do this for both gulp-tar and gulp-zip

[bytestream]

+1

@obingo suggestion worked a treat. Shame I didn't find it sooner -_-

[auban]

Great

That works fine

Many thanks

[SatadruBhattacharjee]

+1

Thanks for the suggestion. @obingo

[impankratov]

@obingo thank you. Was wondering why i have different permissions, but now everything works as it should on windows machine.

@sindresorhus maybe you could add a little note about mode: null for windows users in a readme?

[xsbchen]

+1

@sindresorhus maybe you could add a little note about mode: null for windows users in a readme?

[kevva]

Maybe that should be set to null automatically for Windows users instead?

[sindresorhus]

This plugin just uses the mode it gets from Vinyl or rather gulp.src(). I think it should be fixed there instead.

[BrandonLWhite]

The above recommended workaround fixed the directory execute permissions for me, but it broke execute permissions I was adding to some other files (bash/script files that are packaged in the tarball) using gulp-chmod. Fortunately I was able to use gulp-chmod to solve the directory permission issue without disturbing permissions I'd set on other files.

This is an alternative workaround to the mode: null that may be better for those needing to also set permissions on individual files.

Here is an example:

var chmod = require("gulp-chmod");

return gulp.src(_src)
    .pipe(chmod(null, { execute: true }))
    .pipe(tar(PACKAGE+'.tar'))
    .pipe(gzip())
    .pipe(gulp.dest(DIST));

[jlherren]

I'm having the same issue and the {mode:null} solution works fine.

However I would like to point out that this goes beyond just a missing 'x' bit on directories. It causes a serious security issue because some of my files are randomly getting 'rw-rw-rw' permissions, that is, they are world writable upon extraction! The 7zip screenshot confirms that this is how the permissions are stored in the tar.gz.

Noteworthy: Not all entries are affected, just some. However it seems quite random because neither Windows' property dialog, nor cygwin, nor mingw show anything justifying 'rw-rw-rw-' on any of those entries. In fact all three show the exact same permissions on all files (except for 'x' of course).

[huaichaow]

{mode:null} dose not work on windows

• "gulp-tar": "^4.0.0",