-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
copy is not following symlinks correctly, only creates empty directory #276
Comments
In https://github.com/gruntjs/grunt/blob/master/lib/grunt/file.js file.copy runs |
I am seeing the same behaviour after upgrading grunt to |
@hrj same here. Did you file an issue with the Grunt package? If not, I'll go ahead and do it. I don't know much about the inner workings of Grunt, but I'm happy to help with suggesting a fix. |
@karllhughes I never reported it in the grunt package - that line I mentioned could be the culprit, but I didn't have time to do any proper testing on it. I wasn't 100% sure it wasn't a quirk of the copy package, so thought it best to start here, although copy seems to mostly just call file.copy. |
@tobyroworth I actually think it is a deficiency in this package (possibly based on changes in the primary grunt package). The grunt package includes methods for I'm working on a fix to propose. I've never worked with grunt internals before though, so it'll take me a little time to figure out how exactly everything works. |
@karllhughes sound like a good start. You might need to recurse manually though, to get around the check in the grunt package. I think there's a file.recurse, but I might be thinking of a Go library! gruntjs/grunt#371 is worth a look, as it covers the opposite of this issue (and explicitly states file.copy should follow symlinks) |
@tobyroworth just out of curiosity, were you testing this on Mac or Linux? I pulled the project down and wrote a symlink test on my Mac and it seems to be working. Then I tried it on my Linux box and it didn't work. Could be an issue with the way Linux handles symlinks? Also could be a Node thing (I'm using Node 6 on my Mac, but Node 4 on the Ubuntu server). |
@karllhughes tested on Linux (on cloud9 - have a test workspace I used to verify the bug report if you're interested: (https://c9.io/tobyroworth/grunt-copy-test) I updated grunt (to 1) and node (to 5, I think - whatever "stable" was at the time) at the same time, so not sure if it's a node thing or a grunt thing, but the problem happened in fresh container, with only what was necessary installed/updated, and an old one I was developing in.
I'll try updating node and see what happens |
Nope, node 6.1.0 doesn't fix it on Linux |
I'm also having the issue on my Mac with both node 5 and 6. It only breaks when updating grunt from 0.4.x to 1.0.1. Did anyone report in that project? |
This is actually caused by a breaking change in node-glob which is the underlying module used by grunt, see isaacs/node-glob#139. So to get back the old behavior of following symlinks simply specify follow:true as part of file matching option, for which grunt will pass along to node-glob according to http://gruntjs.com/configuring-tasks#files. |
@mwsam just tried it, and it didn't seem to make a difference:
|
It seems follow:true is effective only for ** matching. I faced the same empty directory problem as you but my config is a bit different:
A symlinked directory under client/ will just be copied as empty directory if follow:true is not used. |
Adding |
When copying a symlink, I've usually expected the contents of the link's target directory to be copied. Since updating to Grunt 1.0 an empty directory with the name of the symlink is created, with no contents.
Sample gruntfile.js:
link created with
ln -s test2 test3
test2
containsfile1
andfile2
Folder structure before running grunt (
ls -lR test*
):Folder structure after running grunt (
ls -lR test*
):test1/test3
should containfile1
andfile2
, but is empty. It's also not a symlink to test2, which would be kind of understandable.The text was updated successfully, but these errors were encountered: