fossil clean follow symlinks. bug?
(1) By anonymous on 2020-10-07 08:17:54 [source]
how to reproduce:
mkdir some-repo important-data echo datadata > important-data/mydata cd some-repo/ fossil init .repo > /dev/null fossil open .repo > /dev/null ln -s ../important-data link cat ../important-data/mydata fossil clean > /dev/null cat ../important-data/mydata
datadata cat: ../important-data/mydata: No such file or directory
It is very dangerous behavior.
(2) By MBL (RoboManni) on 2020-10-07 11:17:00 in reply to 1 [link] [source]
Probably the next question will be which
fossil version you are using.
(3) By Warren Young (wyoung) on 2020-10-07 11:34:08 in reply to 2 [link] [source]
And whether you’re trying to use a versioned allow-symlinks setting, which isn’t allowed anymore for security reasons I’m not clear on. You have to set it per machine or per repo now,
(4) By MBL (RoboManni) on 2020-10-07 11:53:17 in reply to 3 [link] [source]
Going as Admin into the Settings the 3rd from top on the left is a checkbox allow_symlinks (in my case NOT checked).
Fossil 2.13 [449ab5d600] 2020-09-16 13:58:31 UTC The "allow-symlinks" setting: When allow-symlinks is OFF, Fossil does not see symbolic links (a.k.a "symlinks") on disk as a separate class of object. Instead Fossil sees the object that the symlink points to. Fossil will only manage files and directories, not symlinks. When a symlink is added to a repository, the object that the symlink points to is added, not the symlink itself. When allow-symlinks is ON, Fossil sees symlinks on disk as a separate object class that is distinct from files and directories. When a symlink is added to a repository, Fossil stores the target filename. In other words, Fossil stores the symlink itself, not the object that the symlink points to. Symlinks are not cross-platform. They are not available on all operating systems and file systems. Hence the allow-symlinks setting is OFF by default, for portability.
(7) By MBL (RoboManni) on 2020-10-07 12:35:26 in reply to 4 [link] [source]
One question regarding windows ... are the link files with file extension .lnk the same as a symlink on Linux ?
As I read the text above I would have done it the other way around: not checked to handle the link file and checked the referenced target file.
Maybe this was also the understanding of the thread originator !?
(5) By Stephan Beal (stephan) on 2020-10-07 12:19:51 in reply to 3 [link] [source]
versioned allow-symlinks setting, which isn’t allowed anymore for security reasons I’m not clear on
Because it allows someone else to toggle symlink support on for your system. During the recent sprint of security-relevant fixes it was decided that symlinks, being a potential source of security problems, should not be turned on unless a given user decides to do so, in which case they must turn it on themselves. It was a "better safe than sorry" decision, IIRC.
(6) By anonymous on 2020-10-07 12:25:39 in reply to 1 [link] [source]
For what it's worth:
(On Linux) I see the same file-in-symlinked-directory-is-deleted-without-prompt when using a freshly downloaded binary of
This is fossil version 2.132020-09-26 11:24:24 UTC
and I see that file not deleted when using a rather old
This is fossil version 2.92019-07-13 13:05:19 UTC
In the first case, "fossil clean -n" did say
Removed unmanaged file: link/mydata
where the second case said
Removed unmanaged file: link
"fossil undo" re-creates the link to the directory in the second case; and re-creates the link to the directory and brings back the file in that directory in the first case. It reports
"fossil settings" shows 60 lines for the old one, and 72 for the new. "allow-symlinks" is blank in both, as are most values (access-log, admin-log, autosync are 1; localauth is 0; in both; the rest are blank (presumably "default").
So - yes, "clean" is dangerous, but it does report
"fossil undo" is available to undo changes to the working checkout.
if you let it; and "undo" does what it says (at least, if it is run soon enough).
I'm not commenting on whether the changed behaviour is a bug or not.
(9) By anonymous on 2020-10-07 14:44:13 in reply to 6 [link] [source]
fossil clean removes symlink, not data it points to.
git clean works as expected.
(8) By anonymous on 2020-10-07 14:40:30 in reply to 1 [link] [source]
$ fossil ver This is fossil version 2.12.1 [b98ce23d4f] 2020-08-20 13:27:04 UTC $ fossil undo cannot write to /tmp/tmp.ivfyFKxEm8/some-repo/link/mydata because non-directory object /tmp/tmp.ivfyFKxEm8/some-repo/link is in the way $ fossil set allow-symlinks allow-symlinks
(10) By anonymous on 2020-10-08 15:24:32 in reply to 8 [link] [source]
Again, for what it's worth:
(same AC as message (6) above)
I see the same looks-like-data-loss (of something *not* managed by fossil) issue with that version
This is fossil version 2.12.12020-08-20 13:27:04 UTC
but not with the newer one.
fossil clean -n
Removed unmanaged file: link/mydata
and "fossil clean" does that (without deleting the symlink); then "fossil undo" fails to restore the file with the same
cannot write to ... because non-directory object ... is in the way
Some (very) brief testing suggests that the "mydata" content is gone.
Prior to running "fossil undo", it was available.
If you had done "rm link; mkdir link" before "fossil undo", it would have been restored to the "link" directory (but not to ../important-data).
But when "fossil undo" failed to successfully restore the content, it also discarded the content from its local (.fslckout) store.
- You get to learn how good your backups are :-(
- Newer fossil does not fail to "undo" in this case
- I have no idea if newer fossil keeps or removes the local copy of the content, if a "fossil undo" ever does fail -- that might be interesting to check, for future-proofing.
(11.1) By Richard Hipp (drh) on 2020-10-09 23:37:10 edited from 11.0 in reply to 1 [link] [source]
Here are the results of bisect.
(12.1) By Richard Hipp (drh) on 2020-10-10 00:05:07 edited from 12.0 in reply to 11.1 [link] [source]
The prior (unedited) version of this post was incorrect. The problem was introduced during the current development cycle. It was a typo: "=" used where "==" was needed. Fix by check-in 4d445ead4cdca1ff.