DELETE EVENTS ============================================ PRESENTATION When it comes to handling the deletion of files (local or remote -FTP/SSH/etc-), Zeitgeist supports the logging of DELETE_EVENTs, but that's about it. There's no clear distinction between what exists and what doesn't. The addition of the current_uri field made this worse, since if a file X is deleted and at some later point a new file is created with the same name they will be considered the same. PROPOSAL I propose two measures that should give us some pretty reasonable handling of deletions: a) Extend the StorageMonitor extension with a concept of "deleted resource". Insertion of DELETE_EVENTs (for local files, and possible ftp/sftp/etc) will update the value of "storage" where appropriate so the deleted events will be filtered out when querying with StorageState.AVAILABLE. b) In the engine itself, process DELETE_EVENTs by updating the "current_uri" of relevant subjects. The new URI will take a form like "deleted://%d" where %d is an identifier unique for each deletion (incremental integer, most likely). RANDOM (UNRELATED) THOUGHTS * This just made me think, would it make sense to add a new "resource" table for data shared between subjects (ie. current_uri and storage)? * Also, would a current_origin field be useful? Launchpad bug - https://bugs.launchpad.net/zeitgeist/+bug/954206
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/zeitgeist/zeitgeist/issues/15.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.