Salt: File.managed will not replace a symlink

[JaseFace]

Description of Issue/Question

Using file.managed to write a file will follow the symlink and write to the sym destination when the default of follow_symlinks is set to true. When you use follow_symlinks: False, Salt fails to overwrite the symlink and errors with:

    Function: file.managed
    Name: /etc/somefile.conf
    Result: False
    Comment: Unable to manage file: 'NoneType' object has no attribute 'startswith'

Setup

Try to overwrite a file that's currently a symlink:

somefile:
  file.managed:
    - name: /etc/somefile.conf
    - follow_symlinks: False

Versions Report

Salt Version:
           Salt: 2015.8.7

Dependency Versions:
         Jinja2: 2.7.3
       M2Crypto: 0.22
           Mako: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.6.0
         Python: 2.7.10 (default, Jul 21 2015, 21:44:29)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.2
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.3
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
        libgit2: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.2
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: Not Installed
        timelib: Not Installed

System Versions:
           dist:
        machine: amd64
        release: 10.1-STABLE-llnw19

[jfindlay]

@JaseFace, thanks for reporting.

[bgdnlp]

Still true for 2016.11.2 running on Ubuntu 16.

To clarify, the expectation is that when follow_symlinks is False and a symlink exists in place of the file, the symlink is removed and a new file is created.

Workaround, for anyone stumbling upon this issue:

remove /path/somefile symlink:
  file.absent:
    - name: /path/somefile
    - onlyif:
      - test -L /path/somefile

/path/somefile:
  file.managed:
    - contents:
      - 'I am not a symlink'
      - '#someta'

[joshenders]

Was caught by surprise by this as well. Will the solution above always remove the symlink first or is there a case where the file could be copied first (and clobber whatever the symlink is pointed to)?

edit: there's probably a more elegant way but this seems to have worked:

/path/somefile:
  file.managed:
...
    - onlyif:
        - test -n /path/somefile

[teran-mckinney]

Running into this with writing /etc/resolv.conf when it's been set by systemd-resolved as a symlink.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[teran-mckinney]

Think this is still active from what I know.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[birarda]

Just tested this from a 2018.3.0 salt master to a 2019.2.3 salt minion and the expected behaviour occurred (a file.managed with follow_symlinks: False removed the broken symlink).