Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
GLib
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 926
    • Issues 926
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 61
    • Merge Requests 61
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • GLib
  • Issues
  • #446

Closed
Open
Opened Sep 07, 2011 by bugzilla-migration@bugzilla-migrationReporter

new subscriptions can report old events from an existing directory watch

Submitted by Peter Clifton

Link to original bug (#658491)

Description

I've been having some issues with file-change monitoring, where I hook up a GFileMonitor to a file just after having changed it on disk. This only occurs in the case where a second monitor exists on the directory in question. (In this case, left hanging around due to a possible bug in the GTK file-chooser).

It appears that the GIO backend code has a bit of a race, in that it can queue up events for a directory - then process them at some later time (after my new subscription is added).

The OLD events match against the new subscription, and are dispatched - despite the events predating the subscription.

Should adding a new subscription force processing of any events up to that point (before adding the new subscription), or would this be something that could be handled by looking at the timestamp on the events?

Version: 2.28.x

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/glib#446