SUMMARY:
    In certain cases, baloo does not notice that a file or folder has been renamed.

    Baloo recognises that a file or folder has been renamed with a 'mv'. If however
    the rename is done by creating a hard link with the new name and then deleting
    the original (as might be done to avoid overwriting a destination file without
    risking a race condition) baloo treats the file/folder as deleted.

STEPS TO REPRODUCE:
    Install inotifywait and create a test file:

        $ cd Documents
        $ echo "Hello Penguin" > file1.txt

    Open two windows, run "inotifywait -m Documents" in one
    and "balooctl monitor" in the other.

    Rename the test file with mv:

        $ mv file1.txt file2.txt

    Recreate the testfile and rename it with

        $ echo "Hello Penguin" > file1.txt

        $ balooshow file1.txt

        $ ln file1.txt file2.txt

        $ balooshow file2.txt

        $ rm file1.txt
        $ balooshow file2.txt

OBSERVED RESULTS
    When renaming with "mv", you see inotifywait showing the rename and
    baloo tracks the change.

        Documents/ MOVED_FROM file1.txt
        Documents/ MOVED_TO file2.txt

    When linking a new name and unlinking the old, baloo sees the file (as
    it had the same ID) as deleted:

        $ echo "Hello Penguin" > file1.txt

        $ balooshow file1.txt
        1493810000fc01 64513 1348481 file1.txt [/home/test/Documents/file1.txt]
                Mtime: 1654284118 2022-06-03T21:21:58
                Ctime: 1654284118 2022-06-03T21:21:58
                Cached properties:
                        Line Count: 1

        $ ln file1.txt file2.txt

        $ balooshow file2.txt
        1493810000fc01 64513 1348481 file2.txt [/home/test/Documents/file1.txt]
                Mtime: 1654284118 2022-06-03T21:21:58
                Ctime: 1654284118 2022-06-03T21:21:58
                Cached properties:
                        Line Count: 1

        $ rm file1.txt

        $ balooshow file2.txt
        1493810000fc01 64513 1348481 file2.txt: No index information found

    with inotifywait showing:

        Documents/ CREATE file2.txt
        Documents/ DELETE file1.txt

EXPECTED RESULTS
    A rename and a link/unlink behave the same way. In an ideal world(*) baloo
    should be able to cope with a link/unlink.

SOFTWARE/OS VERSIONS
    KDE neon Unstable Edition
    Plasma: 5.25.80
    Frameworks: 5.95.0
    Qt: 5.15.4

ADDITIONAL INFORMATION
    Investigated because of:

        https://invent.kde.org/frameworks/baloo/-/merge_requests/79

    with an underlying change:

        https://codereview.qt-project.org/c/qt/qtbase/+/199004

    This seems to have been around for a while but it's not clear how
    often this "link/unlink" behaviour actually happens - if I look with
    strace, it shows Dolphin doing a "rename".

    There is a thread:

        https://lists.qt-project.org/pipermail/interest/2019-June/033286.html

    saying that the code falls back to link/unlink if a renameat2 fails

    The "*" is there because baloo is built round a one file / one identifier
    model, multiple hard links will confuse it. Some extra magic would be needed.