Fossil Forum

fossil clean follow symlinks. bug?
Login

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

expected output:

datadata
datadata

actual output:

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.

(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.13 [1347e990ac] 2020-09-26 11:24:24 UTC

and I see that file not deleted when using a rather old

This is fossil version 2.9 [0fd79a3e09] 2019-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

NEW link/mydata

or

NEW link

respectively.

"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.

Cheers,

(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 !?

(8) By anonymous on 2020-10-07 14:40:30 in reply to 1 [link] [source]

additional info:

$ 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      

(9) By anonymous on 2020-10-07 14:44:13 in reply to 6 [link] [source]

I expect fossil clean removes symlink, not data it points to.

git clean works as expected.

(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.1 [b98ce23d4f] 2020-08-20 13:27:04 UTC

but not with the newer one.

fossil clean -n

reports

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

message.

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.

So:

  1. You get to learn how good your backups are :-(
  2. Newer fossil does not fail to "undo" in this case
  3. 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 problem has apparently always existed. It just only occurs when the allow-symlinks setting is off. The change in check-in f741baa6be994348 was to make allow-symlinks off by default.

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.