dvc add deletes file when cache type fails on Windows

[gamis]

Setup

• Windows client, where support for symlinks clearly didn't get applied. This has happened on all our Windows machines. It may have something to do with the way our corporate IT has set up Windows.
• Shared dvc cache on a samba mount. Samba server happens to be 3000 miles away from client.
• cache type symlink

Situation

• Try to add a file via a line like dvc add foo.dat.
• File gets hashed, appears to get uploaded to cache, but then no .dvc file is created, the local copy of foo.data is _deleted_, and then dvc raises a "No cache types left to try" error when trying to symlink from the cache back to the local directory.
• Basically, you're left with no local copy of the file, but also no md5 hash of the file to locate it in the cache!
• Change the local cache.type to copy and everything works fine.

I understand the symlink creation failing, but I don't understand why that error should result in the loss of data!

DVC version: 1.8.1 (exe)
 Platform: Python 3.7.9 on Windows-10-10.0.17763-SP0
 Supports: All remotes
 Cache types: symlink
 Cache directory: NTFS on Z:\
 Workspace directory: NTFS on D:\
 Repo: dvc, git

[pmrowla]

So in this case what's probably happening is that technically the data is not lost since the files are properly moved into the cache (on your SMB share). However, due to our cache.save behavior we end up making it look like a loss of data because of the symlink failure (and we don't provide any useful information for recovering the file from cache).

The issue is that for cache.save the move from workspace to cache on its own is atomic, but the entire "move + link" step is not if the link fails.

I think what we should probably be doing here (when the cache file is created, but only the link fails) is to consider the add successful and create the .dvc file, and then raise a troubleshooting message suggesting something along the lines of "try configuring a different link type and then rerun dvc checkout ...".

Alternatively, we would need to adjust cache.save to be properly atomic - so if the link step fails, we would need to copy the file from cache back into the original workspace location.

@efiop thoughts?

[gamis]

Technically no loss of data, agreed, but data that you can't access is still data loss from the user's perspective!