Permissions are not kept when copying files about file-utils HOT 20 CLOSED

This should be fixed on the lastest master of File-utils.

Care to test it before next release on NPM?

from file-utils.

ok, gonna test in a couple of hours

from file-utils.

Hum I'm testing, but it crashes indeed (no problem with my generator with 0.1.5)

Here is some debug:

fs.js:821
  return binding.chmod(pathModule._makeLong(path), modeNum(mode));
                 ^
Error: ENOENT, no such file or directory '/cwd/path/web/favicon.ico'
    at Object.fs.chmodSync (fs.js:821:18)
    at Env.File.copy (/path/generator/node_modules/yeoman-generator-dj/node_modules/file-utils-git/lib/file.js:322:10)
    at Env.copy (/path/generator/node_modules/yeoman-generator-dj/node_modules/file-utils-git/lib/env.js:31:32)

chmod seems to be done all the time, but it crashes if this.src hasn't yet copied the file, something like that ?

Pay attention to this.dest also, to put permissions at the very last step (after real copy)

from file-utils.

You could let your user reopen issues ;)
(I don't have the button to perform that)

from file-utils.

Further information, this crashes occurs in my generator, but also with the simple generator I've provided at the beginning of this issue

So you should be able to reproduce it with this minimalistic generator
(be sure to launch the generator in a directory that is empty !, otherwise, if the other-foobar1.sh already exists locally, then the bug doesn't appear, and permissions are correctly preserved as expected)

from file-utils.

@SBoudrias Any news on this issue ?
Thanks again for this wonderful lib ;)

from file-utils.

Nothing yet.

I'm not even sure anymore it make sense to keep the same permission when copying... When I'm on a Unix system, I always set the group ID of my folders in order to copy everything with the expected permissions. Check it out, it is the chmod g+s permission.

from file-utils.

To be honest, I've never used this chmod command :)

But the first need for me is in fact to preserve the executation flag on linux. I've reported this issue in yeoman, and the one who fixed it (don't remember well, maybe @passy), choosed a generic way, which is to preserve all flags, instead of just specific one

This fix in yeoman was inspired by the same code from grunt that preserves files permissions

convinced to debug the permission preserved ?
I hope so :)

from file-utils.

Well, this is a fork of the Grunt code base. Copy does not preserve permissions in Grunt, that's why I'm concerned.

from file-utils.

Here is the issue in yeoman where permissions preservation has been added
yeoman/generator#235

It refers to a new issue for grunt:
gruntjs/grunt#732

It seems that it's going to be added

Definitely hope it will be added to file-utils, I really need it :)

from file-utils.

Try chmoding your stuff correctly before saying you really need it ;)

from file-utils.

I've performed a chmod g+s ~, also chmod g+s .cache/yeoman but permissions are not preserved
Maybe I would need to chmod recursively ? but the .cache/yeoman/XX where the remote store the fetched package is cleaned each time I run my generator

but, to be honest, even if the chmod g+s works in some way, I prefer that my generator doesn't rely on it, and preserve permissions even if this chmod has not been done (it's not done by default on my ubuntu 13.10 for example)

You prefer to wait for this feature to be included into grunt before including it into file-utils ?

if this is case, you may revert your last change on the master branch, to get previous behavior
(I keep on having a problem, as exposed above)

And thanks to your filter, I guess I could add this permissions preservation, specific to my need

from file-utils.

I've done further tests, I've massively added a chmod g+s on every directory from which my generator copies files to another destination
And unfortunately, it doesn't preserve permissions

I've tried to create this preservation in a filter, but as the filter doesn't write the file, but prepares files to be written, I cannot change permissions at this step I guess

I'm clueless to preserve those flags

Any idea how to use this chmod or another command to force the preservation of flags ?

Thanks!

from file-utils.

You'd want to recursively apply the chmod to your directory structure first: find <DocumentRoot> -type d -exec chmod g=rwxs,o=x {} +

Then, you'd want to set the permissions so group have it's right on the files too: find <DocumentRoot> -type f -exec chmod 664 {} + (maybe chmod to 7 for files you need to exec)

Then you'd want to setup your system umask so Group keep permissions (umask 003, but you need to set it in the .bash profile of your terminal so it is always setup correctly).

The only thing missing is how you choose the owner group - well that really depends on you... You can run id <username> to see which group your user belongs. If necessary, create a new group and add relevant users in it.

from file-utils.

Ok thanks
I've tried all that, and an even more permissive permissions, with the correct umask set before launching my generator, and permissions are still lost

I have a question however, but first, here is the process followed by my generator basically:
it remote() a package on github (symfony-standard), in order to fetch it in cache (~/.cache/yeoman/symfony-standard/v2.4.0 actually), then it copies those files from cache to my cwd

symfony-standard uses standard permissions (755 on dir, 644 on files, no specific user/group set), with some executable files. I'd like then to have in my cwd, those executable files. Unfortunately, I get all files with 644 mode (my standard umask being 0022).
So I cannot anymore run those executable files from my cwd

I'm using file-utils in the yeoman generator, with a filter, but I guess that it opens a new file, in order to store in it some content processed by the filter, it's not a common cp, but an open followed by a write I would say no ?

So maybe, all those setuid stuff may not help ? only umask may help, but I don't want to have all my files executable. I just need to make executable the files that are executable in the cache

Lastly, I will work on this workaround: scan for files that are executable in cache, launch the generator, and at the very end, scan again to apply the exec flags to corresponding files in my cwd (I need however to have in my cwd the exact structure that exists in cache, to deduce the target from the source path), because I don't have the source path in the filter.

Btw, maybe it would be nice to give in data (the parameter given to the filter), the source path also ?
(I have already the target name of the file, and its content, but not its source path)

If you know a better way to make those permissions kept, don't hesitate !

Thanks for your help

from file-utils.

I think I'll just persist the executable bits then.

from file-utils.

Thanks!

asap you ping me, I'll test!

from file-utils.

Hey! It should be fixed on latest master. Care to give it a shot?

I'll release a new version soon.

from file-utils.

thanks @SBoudrias gonna test soon

from file-utils.

@SBoudrias Sorry for the delay
I've tested with last 0.2.0, and it works like a charm, thanks!

from file-utils.