-
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
Symlinks as symlinks #131
Symlinks as symlinks #131
Conversation
Thanks for the pull request, could you please squash the commit into one commit. |
|
||
If set to false, `dest` file will contain data from the `src` symlink's target. | ||
|
||
Under Windows, the option has no effect, i.e. is always `false`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this? Can Windows not copy symlinks or what is the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows have a lot of problems with symlinks, it doesn't work properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to work on Windows to merge. What issues do you have with symlinks on Windows? What version of Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
This seems like something that should belong in |
I agree with this. But now, |
It will fail, if symlink links to a directory. |
@LMnet I've made a pull request to your fork that adds support of copying symbolic directory links mr-moon@ce599e9 |
Added ability to copy symlinked directories
I finally created workaround for Windows. I tested on Windows XP, Windows 7 and Ubuntu Linux, and all tests are succesfully passed. |
grunt.file.mkdir(dest); | ||
if (options.copySymlinkAsSymlink && isLink) { | ||
try { | ||
fs.symlinkSync(fs.readlinkSync(src), dest); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully understand what you mean. Can you give some more details?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, two cases, both start with a symlink /foo/bar
to a directory /baz/dir/
that we want to copy to /beep/boop
:
- When
/beep/boop
already exists copy will fail. Ifbar
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. - When neither
/beep/
nor/beep/boop
exist, copy will fail trying to writeboop
to the non-existant/beep/
directory. Again ifbar
linked to a file instead of a directory, we'd first create/beep/
then copy inboop
. Should also be consistent.
@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. |
@shama If we can get a PR in for this on Grunt I will merge and publish it as a patch release. |
@vladikoff grunt, hopefully soon I'll get around to a pull request. I'm completely overloaded atm. |
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? |
This pull request can really closed this issue.