[Kst] [Bug 293822] New: kst doesn't monitor dirfiles for metadata changes

[D. V. Wiebe]

https://bugs.kde.org/show_bug.cgi?id=293822

Summary: kst doesn't monitor dirfiles for metadata changes
Product: kst
Version: 2.0.4
Platform: Unlisted Binaries
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: datasources
AssignedTo: ***@kde.org
ReportedBy: ***@ketiltrout.net


I've run into a problem due to kst not monitoring a dirfile's metadata on disk
while working on defile (an {"anything"} to dirfile converter program).

When kst is reading from a dirfile which is truncated by a third party calling
GetData's gd_open(..., GD_TRUNC) on it, a race condition exists in kst. This
call results in a dirfile with no fields in it. The third party can then add
fields to the dirfile and flush the metadata to disk.

If kst updates the datasource after truncation but before the new metadata has
been written to disk, it will get a DIRFILE with no fields in it. In
particular, this means that gd_nframes() will always return zero. Because kst
doesn't monitor the dirfile's metadata for changes, the third party creating
fields later doesn't fix this problem.

So: kst should monitor an open DIRFILE file for metadata changes and trigger a
reload of datasource if it notices change. Things get a little difficult
because the dirfile metadata can be spread across multiple files.

I think it's sufficient to monitor the primary format file. Kst can figure out
the path of this file itself: it's just whatever pathname kst passed to the
GetData::Dirfile constructor + "/format". However, if it's easier, the name is
also available via GetData. A more complete solution would be to monitor every
fragment.

[D. V. Wiebe]

https://bugs.kde.org/show_bug.cgi?id=293822

--- Comment #1 from D. V. Wiebe <***@ketiltrout.net> ---
Not that I'm necessarily advocating it's use, but GetData-0.8 now provides
Dirfile::DeSync() (= gd_desync()) which performs such monitoring and can,
optionally automatically reload the dirfile if changes are detected.

The down side of this function is that it uses the mtime returned from stat(2)
to determine if a file has changed. This makes it both portable on anything
providing something resembling a sysV stat(), including Win32, and also not
dependent on external dependencies, but does limit the granularity of changes
to one second, which can result in this function being unable to detect changes
to a dirfile in certain exceptional circumstances (see gd_desync(3) for a
discussion). Using FAM/inotify/whatever would be a better but non-portable
solution.

[Andrew Crouthamel]

https://bugs.kde.org/show_bug.cgi?id=293822

Andrew Crouthamel <***@kdemail.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WAITINGFORINFO
Status|REPORTED |NEEDSINFO

--- Comment #2 from Andrew Crouthamel <***@kdemail.net> ---
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test
if the bug is valid in the latest version? I am setting the status to NEEDSINFO
pending your response, please change the Status back to REPORTED when you
respond.

Thank you for helping us make KDE software even better for everyone!

[Andrew Crouthamel]

https://bugs.kde.org/show_bug.cgi?id=293822

Andrew Crouthamel <***@kdemail.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |REPORTED
Resolution|WAITINGFORINFO |---

--- Comment #3 from Andrew Crouthamel <***@kdemail.net> ---
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you
help us out and re-test if the bug is valid in the latest version? This bug
will be moved back to REPORTED Status for manual review later, which may take a
while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!