In contrived circumstances, repro of an added file with hardlinks enabled results in a not-read-only file

[charlesbaynham]

DVC 0.93.0, Windows 10

This is a quite contrived Issue, so please feel free to close it on the grounds that anyone messing around with .dvc files manually deserves what's coming to them. However:

Doing the following steps works fine:

git init
dvc init
dvc config cache.type reflink,hardlink,copy

echo Hello world > out.txt

ls -l out.txt
# returns -rw-r--r--
dvc add out.txt
ls -l out.txt
# returns -r-r--r--
dvc repro out.txt.dvc
ls -l out.txt
# returns -r-r--r--

Once out.txt is added to the cache, it's made read-only as it should be.

However, if you then alter out.txt.dvc, e.g. by deleting the md5 entry, running dvc repro out.txt.dvc results out.txt being restored, but now it's unprotected:

# Now manually alter the .dvc file, removing the md5 entry but leaving the outs: section untouched
tail -n +2 out.txt.dvc > tmp
mv tmp out.txt.dvc

dvc repro out.txt.dvc
ls -l out.txt
# returns -rw-r--r--

Like I said, a bit contrived, but might point to something funny going on in repro when used for added files.

I bumped into this problem because I generated .dvc files with only the outs filled in then used dvc checkout to load these files from the cache. I noticed that these .dvc files didn't have the md5 fields filled in, so I ran dvc repro to make a fully formed file. This worked, but made the files writable as described.

[pared]

#!/bin/bash
rm -rf repo
mkdir repo

pushd repo
git init --quiet
dvc init -q
dvc config cache.type reflink,hardlink,copy

echo data >> data
ls -l | grep data

dvc add data -f stage.dvc -q
ls -l | grep data

dvc repro stage.dvc
ls -l | grep data

sed -i "s/6137cde4893c59f76f005a8123d8e8e6//g" stage.dvc
cat stage.dvc

dvc repro stage.dvc
ls -l | grep data

Seems that on linux the permissions do not change. I think that there should be no disrepancy between systems. Marking as bug.

[efiop]

Closing as stale.