[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: kst at kde.org
        ReportedBy: dvw at 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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.