Symlinks as symlinks

[LMnet]

This pull request can really closed this issue.

[vladikoff]

Thanks for the pull request, could you please squash the commit into one commit.

[vladikoff]

Why is this? Can Windows not copy symlinks or what is the issue?

[LMnet]

Windows have a lot of problems with symlinks, it doesn't work properly.

[shama]

This needs to work on Windows to merge. What issues do you have with symlinks on Windows? What version of Windows?

[LMnet]

Only Windows Vista and above can handle symlinks. And git clone transform symlinks on windows into the regular files. I need some time to solve this problems.

[shama]

This seems like something that should belong in grunt.file.copy instead of just implemented in this task. /cc @tkellen

[LMnet]

This seems like something that should belong in grunt.file.copy instead of just implemented in this task.

I agree with this. But now, grunt.file.copy can't copy symlinks, and I found, that fixing grunt.file.copy is a lot more complex goal. In my project (I'm using grunt to build desktop C++ application) I really need to copy symlinks as symlinks on linux. I decided to take the easy way: fix the problem in this repo.

[mr-moon]

It will fail, if symlink links to a directory.

[mr-moon]

@LMnet I've made a pull request to your fork that adds support of copying symbolic directory links mr-moon@ce599e9

[LMnet]

I finally created workaround for Windows. I tested on Windows XP, Windows 7 and Ubuntu Linux, and all tests are succesfully passed.
I'm waiting for review. After that I will squash commits.

[hurrymaplelad]

Needs to create parent dir, delete link if it exists, as below:

  grunt.file.mkdir(path.dirname(dest));
  if (grunt.file.exists(dest)) {
    grunt.file.delete(dest);
  }

[LMnet]

I don't fully understand what you mean. Can you give some more details?

[hurrymaplelad]

Sure, two cases, both start with a symlink /foo/bar to a directory /baz/dir/ that we want to copy to /beep/boop:

1. When /beep/boop already exists copy will fail. If bar were a symlink to a file instead of a directory, the code below would delete the existing symlink, /beep/boop/ before creating the new one, and pass. Seems like behavior should be consistent either way. I'd prefer always delete, then create.
2. When neither /beep/ nor /beep/boop exist, copy will fail trying to write boop to the non-existant /beep/ directory. Again if bar linked to a file instead of a directory, we'd first create /beep/ then copy in boop. Should also be consistent.

[shama]

I still think this belongs in grunt.file.copy instead of this task. /cc @tkellen @cowboy

[mr-moon]

@shama we still agree with you. You may just leave this pull open, so others, who fall into same circumstances as we, may still fork and benefit from it.

[tkellen]

@shama If we can get a PR in for this on Grunt I will merge and publish it as a patch release.

[vladikoff]

@shama should this go into grunt or grunt-next?

@LMnet it might make it easier for others to use this if you squash this. Make sure to not delete your branch.

[shama]

@vladikoff grunt, hopefully soon I'll get around to a pull request. I'm completely overloaded atm.

[jamesplease]

This issue references #30, but they seem to have two different goals. What I gather from #30 is that the user wants to be able to generate symlinks from actual files (which I suppose is now accomplished by grunt-contrib-symlink), but this issue seems to discuss the problem of copying a symlink as a symlink, instead of creating a new file from a symlink.

The latter issue is really the problem we're trying to solve, right?