Thanks for filing a ticket! I am the friendly GitHub Ansibot. I see you did not fill out your issue description based on our new issue template. Please copy the contents of this template and paste it into the description of your ticket.

Our system will automatically close tickets that do not have an issue template filled out within 7 days. Please note that due to large interest in Ansible, humans may not comment on your ticket if you ask them questions. Don't worry, you're still in the queue and the robots are looking after you.

I believe it is a regression, this feature worked a few days ago and just stopped working now.
In fact, it works in release1.6.1 but not in release1.6.2

It must be a regression, I remember using the same syntax earlier and it used to work fine:

file: src=linux-3.14.4 dest=/usr/src/linux owner=foo group=foo state=link

this works for me

ansible -m file -a "state=link src=../test.yml
path=/home/user/tmp/test2.yml force=yes" -i 'localhost,' all -c local
​
with existing /home/user/test.yml

It's not working for me on ansible 1.7 git 2014-05-25.

Just tried (kernel_ver = 3.14.4, src_main_dir = /usr/src) :

- name: kernel set src symlink
  file: >
    src=linux-{{ kernel_ver }}
    dest={{ src_main_dir }}/linux
    state=link

Output:

TASK: [build | kernel set src symlink] **************************************** 
failed: [work1] => {"failed": true, "gid": 0, "group": "root", "item": "", "mode": "0777", "owner": "root", "path": "/usr/src/linux", "size": 10, "src": "linux-3.14.4", "state": "link", "uid": 0}
msg: src file does not exist, use "force=yes" if you really want to create the link: /root/linux-3.14.4

FATAL: all hosts have already failed -- aborting

I believe this recent patch created the issue:

062e82937f2f97f94e78369306dfedc3f818de91 Fixing absolute path calculation for file module when linking
diff --git a/library/files/file b/library/files/file
index 4ba61f6..32588e5 100644
--- a/library/files/file
+++ b/library/files/file
@@ -191,7 +191,7 @@ def main():

         absrc = src
         if not os.path.isabs(absrc):
-            absrc = os.path.normpath('%s/%s' % (os.path.dirname(path), absrc))
+            absrc = os.path.abspath(src)

​
I was asked about it and did not realize that the previous line was trying to always use the destination (path) as source for the absolute path, vs current working directory. This patch fixed another issue, just need to make a fix that takes both into account.

so my example worked because of force=yes, but both should have worked w/o it, the relative path was calculated incorrectly from recent patch. force=yes should have worked for you but it should not have been required.

PR I submitted should solve all current issues, there is still at least a corner case I need to flush out.

Great, looking forward to the fix thanks! For now using a shell task with " rm -f link ; ln -s source target "

In my case per the error message above, force=yes would have targeted /root/linux-3.14.4 which is wrong.

no, that is only the error message from the incorrect relative source, the
actual link would have been what you expected as it uses the original
relative path you passed in, not the calculated absolute.​

FYI, a eselect module would be a better fix for symlinking the kernel
source on gentoo, it is on my list but its a long list.
​

I’m using Slackware, no eselect there :)

Regards,
—Ed

On May 25, 2014, at 16:07, Brian Coca notifications@github.com wrote:

FYI, a eselect module would be a better fix for symlinking the kernel
source on gentoo, it is on my list but its a long list.
—
Reply to this email directly or view it on GitHub.

my bad, I'm used to all 'build latest kernel' crowed to be on
gentoo/arch/etc​

Thanks for the fix @bcoca! I just ran into this issue when symlinking an Apache configuration on a Debian machine.

Got the same problem with 1.6.2. I'd work around it by specifying force=True until this bugfix gets into next release.

The above commit has been merged in, and should resolve this. Please let us know if you continue seeing any problems related to this issue, thanks!

Thanks for the changes! This works fine for me as long as I use 'force=yes.'
If a symlink by that name already exists (pointing to some other src dir for
example) and I use 'force=no' I get an error - see the scenario below. The
error message "msg: src file does not exist" is wrong - the src dir exists.

I'm perfectly happy with 'force=yes' for now but given the scenario below
things aren't 100% correct somewhere (file module?). Or maybe the file
module docs just need to be updated to indicate a third scenario where
force=yes is required - when a symlink already exists and needs to be
modified to point to a new target.

Existing symlink (in /usr/src):

lrwxrwxrwx  1 root root   13 May 28 10:18 linux -> linux-3.10.17

Ansible task to modify symlink:

- name: kernel set src symlink
  file: >
    src=linux-3.14.4
    dest=/usr/src/linux
    state=link

TASK: [build | kernel set src symlink] **************************************** 
failed: [work1] => {"failed": true, "gid": 0, "group": "root", "item": "", "mode": "0777", "owner": "root", "path": "/usr/src/linux", "size": 13, "src": "linux-3.14.4", "state": "link", "uid": 0}
msg: src file does not exist, use "force=yes" if you really want to create the link: /usr/src/linux/linux-3.14.4

FATAL: all hosts have already failed -- aborting