SYMLINK and UNLINK statuses
(1) By senyai on 2023-05-21 20:06:38 [link] [source]
Hello. According to checkin.c `fossil status` can show SYMLINK and UNLINK classes. I tried `fossil settings allow-symlink on` and added and modified symlinks (ln -s) and status never showed one of those classes, even though fossil ui showed files as symlinks.
(2) By Warren Young (wyoung) on 2023-05-21 22:17:31 in reply to 1 [link] [source]
Those states are to mark files transitioning to and from symlink status, with no other changes observed. SYMLINK means the file was once a regular file and is now a symlink, and UNLINK means the opposite.
(3) By senyai on 2023-05-22 05:50:08 in reply to 2 [link] [source]
Thank you. Now I tested and saw `SYMLINK` status, but no `UNLINK`.
fossil settings allow-symlinks on ln -s /etc/passwd a fossil add a fossil ci -m 'add a' rm a touch a fossil status
Why is here status is `EDITED` and not `UNLINK`?
(4) By Warren Young (wyoung) on 2023-05-22 06:07:32 in reply to 3 [link] [source]
Because it contains different content now. It’s edited.
(5) By senyai on 2023-05-22 06:45:30 in reply to 4 [link] [source]
cp /etc/passwd a won't change the status. I mean how can content not be different?
(6.2) By Warren Young (wyoung) on 2023-05-22 08:18:02 edited from 6.1 in reply to 5 [source]
Your example above doesn't cp the test file, it "touch"es it, which as I said "edits" the file, effectively asking Fossil to compare a zero-byte file with the non-empty contents of /etc/passwd.
However, I believe I see what you mean once you un-confuse the test case:
f init x.fossil
mkdir x
cd x
f open ../x.fossil
fossil settings allow-symlinks on
ln -s /etc/passwd a
fossil add a
fossil ci -m 'add a'
rm a
cp /etc/passwd a
f stat
That shows "EDITED" even though the file content hasn't changed.
What's happening is that Fossil is taking a file size change as evidence of file content change, and that is in turn happening because it's storing the length of the symlink text as the size of the file in vfile.size instead of the size of the referenced content. If you then try to hack around that by checking the hash of the on-disk file against the in-repo hash, you'll still get a mismatch because it's stored the hash of the symlnk text, not the hash of the referenced content, so it can't tell that the old link pointed to a copy of the same data.
I see no way to achieve the UNLINK output given the current design of Fossil.
(7) By senyai on 2023-05-22 12:21:09 in reply to 6.2 [link] [source]
Easy! I made content of new 'a' file equal '/etc/passwd' and fossil showed me UNLINK :) Thank you very much for your help!
(8) By Warren Young (wyoung) on 2023-05-22 20:55:27 in reply to 7 [link] [source]
Are you saying that you did this as the second-to-last step instead of the cp call in my test case above?
echo -n /etc/passwd > a
Other than that, I don't see how you could get Fossil to show UNLINK short of the code change I will shortly be committing.