Well this was passing prior to #11269 😅 promise. I think it has to do with the guards added for if backup == NULL) in that PR

Traivs failure looks unrelated? Failing in the lang_spec over Locale sv_SE.UTF-8 not supported? Not sure about that. As for the linting, I'll fix that as long as its okay to pull in the global helpers directly in to the test file.

However the appveyor is failing bc I added a assertion/expectation about the final contents of the symlink file..., but I remember vaguely that Windows has some weirdness around symlinks... probably okay that I remove those intermediary expectations right?

Any help digging into the "why" behind the travis & appveyor failures would be appreciated. I am very sub-par where Windows is concerned, and I can't duplicate the locale spec failure (nor have I comprehended yet how it relates to this PR) in travis.

travis failure is a UBSAN failure (looks like you already fixed it):

�[32m�[2m[ RUN      ]�[0m�[0m fileio backup symlinked files in first avialable backupdir #11349: �[2m34.32 ms�[0m �[1m�[32mOK�[0m�[0m
==================== File /home/travis/build/neovim/neovim/build/log/ubsan.13780 ====================
= 
= =================================================================
= ==13780==ERROR: LeakSanitizer: detected memory leaks
= 
= Direct leak of 48 byte(s) in 1 object(s) allocated from:
=     #0 0x4c5e63 in malloc /tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
=     #1 0x1115d34 in try_malloc /home/travis/build/neovim/neovim/build/../src/nvim/memory.c:71:15
=     #2 0x1115efc in xmalloc /home/travis/build/neovim/neovim/build/../src/nvim/memory.c:105:15
=     #3 0xdcf982 in modname /home/travis/build/neovim/neovim/build/../src/nvim/fileio.c:4362:14
=     #4 0xdc0a68 in buf_write /home/travis/build/neovim/neovim/build/../src/nvim/fileio.c:2784:32
=     #5 0xb6fc68 in do_write /home/travis/build/neovim/neovim/build/../src/nvim/ex_cmds.c:1799:14
=     #6 0xb70144 in ex_write /home/travis/build/neovim/neovim/build/../src/nvim/ex_cmds.c:1655:11
=     #7 0xc2e39b in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2252:5
=     #8 0xc16f0e in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:621:20
=     #9 0xc1d213 in do_cmdline_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:295:10
=     #10 0x673e65 in nvim_command /home/travis/build/neovim/neovim/build/../src/nvim/api/vim.c:85:3
=     #11 0x58a1d4 in handle_nvim_command /home/travis/build/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:2765:3
=     #12 0x11e12da in request_event /home/travis/build/neovim/neovim/build/../src/nvim/msgpack_rpc/channel.c:382:19
=     #13 0xb31a1e in multiqueue_process_events /home/travis/build/neovim/neovim/build/../src/nvim/event/multiqueue.c:157:7
=     #14 0x129bc96 in nv_event /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:8045:3
=     #15 0x124e519 in normal_execute /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:1131:3
=     #16 0x18fac65 in state_enter /home/travis/build/neovim/neovim/build/../src/nvim/state.c:69:26
=     #17 0x1207159 in normal_enter /home/travis/build/neovim/neovim/build/../src/nvim/normal.c:463:3
=     #18 0xf86fe7 in main /home/travis/build/neovim/neovim/build/../src/nvim/main.c:577:3
=     #19 0x7fba8418a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
= 
= SUMMARY: AddressSanitizer: 48 byte(s) leaked in 1 allocation(s).
=====================================================================================================
�[2mnan ms�[0m test/helpers.lua:180: Found runtime errors in logfile(s): /home/travis/build/neovim/neovim/build/log/ubsan.13780

stack traceback:
	test/helpers.lua:180: in function 'check_logs'
	test/functional/helpers.lua:821: in function <test/functional/helpers.lua:817>

appveyor failures would be appreciated. I am very sub-par where Windows is concerned,

#11269 (comment) shows how to trick AppVeyor into showing hints :) Just compare the value using eq(), and the test failure will show the value.

@justinmk not sure if this is the problem, but libuv uv_fs_copyfile uses CopyFile on windows and that function is affected by whether the file is a symlink or not:

If the source file is a symbolic link, the actual file copied is the target of the symbolic link.

If the destination file already exists and is a symbolic link, the symbolic link is overwritten by the source file.

https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-link-effects-on-file-systems-functions#copyfile-and-copyfiletransacted

So I'm wondering if, by moving to using libuv's copyfile for backup in #8288 we inherented an issue with symlink copy-on-write? Basically I'm wondering if we aren't creating backups for symlniks bc the original file is actually the "link" to the copy-on-write? basically, with how libuv implements the copyfile for windows, I'm wondering if it inherently means that symlinks on windows wants a change to the original file before the "new path" (the backup in this usecase) is written.

Following this last test with Appveyor, I'm even more convinced that it has to do with symlinks behavior with libuv's use of CopyFile on Windows. Is there are contributor that has deeper Windows knowledge that could help? I'm pretty fair out of my element wrt Windows. Other than the searching I've done, I'm not sure what else to do. This PR works for unix & os-x, but can is there a way for it to continue forward without Windows? Technically master is also failing for symlinked file backups on windows fwiw.

Is this PR still blocked for Windows? Maybe it's fixed now after libuv was updated.

Hey! I'll check this weekend and bring this PR up-to-date. I'm also hopeful that the libuv update solved this issue.

#11349 (comment)

see also #18659 and #18704

Oof I completely forgot about this... I just made my dotfiles init scripts just create the ~/.vim-tmp/ directory and moved on... I'm happy for #18704 to supersede. Last I recall the issue with this fix was that it does not work on Windows.

If you want to reduce the places to go and look... you can open this PR back up @justinmk and I can take a stab at it again?

Ah nevermind I see the contributing says to just open a draft PR so I did that instead 😓