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.

Probably the next question will be which fossil version you are using.

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,

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.

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

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.

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

git clean works as expected.

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      

Here are the results of bisect.

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.