Pluma sometimes loses recent files history after reboot (intermittent issue)

[maravento]

Descripción

Pluma intermittently fails to preserve the “Recent Files” history between system reboots or new sessions.
Sometimes the recent files list is saved and reloaded correctly, but other times it resets to empty even though the file ~/.local/share/recently-used.xbel still exists and contains valid entries.
This behavior has been observed across reboots and is not related to AppArmor, permissions, or max-recents settings.

Steps to Reproduce

Open several text files in Pluma (from GUI or terminal).
Close Pluma normally.
Reboot the system or log out and log back in.
Reopen Pluma → sometimes the “Recent Files” list is empty.
Other times it correctly shows the previous files.

Expected Behavior
Pluma should always reload the list of recent files after reboot, as long as the system-wide GTK recent file store (recently-used.xbel) still contains the relevant entries.

Actual Behavior
The list of recent files is inconsistently cleared — works intermittently between reboots

System Information
Ubuntu mate 24.04.3
Pluma version: 1.26.1
AppArmor: tested, no denials found
Permissions: file writable, persists between reboots

ls -l ~/.local/share/recently-used.xbel
-rw------- 1 user user 2426 nov  2 12:48 /home/user/.local/share/recently-used.xbel

cat  ~/.local/share/recently-used.xbel
<?xml version="1.0" encoding="UTF-8"?>
<xbel version="1.0"
      xmlns:bookmark="http://www.freedesktop.org/standards/desktop-bookmarks"
      xmlns:mime="http://www.freedesktop.org/standards/shared-mime-info"
>
  <bookmark href="file:///home/user/test1" added="2025-11-02T17:56:05.247563Z" modified="2025-11-02T17:56:05.247567Z" visited="2025-11-02T17:56:05.247564Z">
    <info>
      <metadata owner="http://freedesktop.org">
        <mime:mime-type type="application/x-zerosize"/>
        <bookmark:groups>
          <bookmark:group>pluma</bookmark:group>
        </bookmark:groups>
        <bookmark:applications>
          <bookmark:application name="Pluma" exec="&apos;pluma %u&apos;" modified="2025-11-02T17:56:05.247566Z" count="1"/>
        </bookmark:applications>
      </metadata>
    </info>
  </bookmark>
  <bookmark href="file:///home/user/test2" added="2025-11-02T17:56:05.284707Z" modified="2025-11-02T17:56:05.284715Z" visited="2025-11-02T17:56:05.284708Z">
    <info>
      <metadata owner="http://freedesktop.org">
        <mime:mime-type type="application/x-zerosize"/>
        <bookmark:groups>
          <bookmark:group>pluma</bookmark:group>
        </bookmark:groups>
        <bookmark:applications>
          <bookmark:application name="Pluma" exec="&apos;pluma %u&apos;" modified="2025-11-02T17:56:05.284711Z" count="1"/>
        </bookmark:applications>
      </metadata>
    </info>
  </bookmark>
</xbel>

Additional Observations

• The file ~/.local/share/recently-used.xbel is never deleted manually, but at unpredictable times its contents shrink or reset to a very small size (2–3 KB), even though valid Pluma entries existed earlier.
• The issue does not occur on another Ubuntu MATE 24.04.3 system with identical Pluma (1.26.1) and user-level settings, where the same file grows normally over time.
• The problem does not happen immediately after logout or reboot; sometimes the recent list survives multiple sessions, but at some later point it gets wiped.
• The file watcher (inotifywait) shows no applications explicitly deleting the file, only modifying it.
  However, at the moment the history disappears, the file is silently rewritten with a minimal header and no Pluma entries.
• No system timer or autostart application on the affected machine appears related; no cleanup services targeting ~/.local/share/.

What I Have Tried

• Verified file permissions; file is writable and owned by the correct user.
• Tested with AppArmor disabled and checked logs: no AppArmor denials.
• Reinstalled Pluma (apt install --reinstall pluma).
• Removed and regenerated recently-used.xbel; issue still occurs.
• Confirmed that Pluma correctly adds entries to the file while running.
• Tested whether GNOME/GTK recent file cleanup tasks exist: none found.
• Compared with a working machine → only one system shows the regression.

Hypothesis (optional)

It appears that GTK’s global recent-files store is being reset or truncated by an external component, not by Pluma itself.
Pluma correctly writes entries, but upon some later session, another process (likely a GTK/MATE component) rewrites the file, eliminating the bookmark:grouppluma</bookmark:group> entries.

More logging or instrumentation may be required to identify which GTK component or MATE daemon rewrites the recent-file store.