I've been experimenting with the index journal logging feature (index_journal_log) and I'm considering building a system that consumes the log files to track file moves and renames in real time.
Before I go further I want to understand precisely how the logging is driven. Specifically:
1. Is the journal log written by the Everything GUI instance, or by the Everything service?
2. If all GUI instances are closed and Everything is running only as a service, does the journal log continue to be written?
3. Conversely, if Everything is running as a GUI app with no service, does the journal stop being written the moment the window is closed?
The reason I ask is reliability — if the journal is GUI-dependent, any accidental window close would silently stop logging and break anything built on top of it. If it's service-driven, it's as reliable as Windows itself.
Running Version 1.5.0.1391a (x64) on Windows 11.
Does index journal logging continue when Everything runs as a service with no GUI instance open?
-
Ralf_Reddings
- Posts: 142
- Joined: Fri Mar 24, 2023 4:53 pm
Re: Does index journal logging continue when Everything runs as a service with no GUI instance open?
The journal log is written by the Everything GUI.1. Is the journal log written by the Everything GUI instance, or by the Everything service?
No.2. If all GUI instances are closed and Everything is running only as a service, does the journal log continue to be written?
Depends on your Tools -> Options -> UI -> Run in background setting.3. Conversely, if Everything is running as a GUI app with no service, does the journal stop being written the moment the window is closed?
When Run in background is enabled, Everything will keep running in the background after you close all the search windows.
The journal log is written while Everything is running in the background.
Run in background is enabled by default.
-
Ralf_Reddings
- Posts: 142
- Joined: Fri Mar 24, 2023 4:53 pm
Re: Does index journal logging continue when Everything runs as a service with no GUI instance open?
Thats clears my questions void, thank you.
The reason why am doing this is I want to make use of the recent metadata.efu feature, that is, to make use of my own custom properties in everything, and by extension in other programmes, via Everything.
Everythings' open standtards aproach to custom properties is much better than what I currently have in place which is ads-stream, which is close ended and just very brittle in general. But metadata.efu has a "orphan" issue, ie when you move files, the metadata stays behind, which is what am trying to see if I can address on my end. I know you said in the other thread you are considering addressing the orphan issue natively in Everything, so I really hope you do decide to, that would be make Everything just perfect.
The reason why am doing this is I want to make use of the recent metadata.efu feature, that is, to make use of my own custom properties in everything, and by extension in other programmes, via Everything.
Everythings' open standtards aproach to custom properties is much better than what I currently have in place which is ads-stream, which is close ended and just very brittle in general. But metadata.efu has a "orphan" issue, ie when you move files, the metadata stays behind, which is what am trying to see if I can address on my end. I know you said in the other thread you are considering addressing the orphan issue natively in Everything, so I really hope you do decide to, that would be make Everything just perfect.
Re: Does index journal logging continue when Everything runs as a service with no GUI instance open?
I've also been starting to make heavy use of the metadata.efu features, and I've had to make custom programs to help me generate them in formats I need (with Gemini's help). Part of what I coded into that flow was flags for -clean (remove all no longer detected items) and flags to detect only if an item was renamed or a recompressed png, and if so, update the existing rows.
However, the more I use it the more I just wish there was a feature to "import" data from metadata.efu files directly into the core database for that property so that it would be remembered if the file moved/renamed (but, if needed, invalidated on content changes), but I think I may just need to return to the idea of building my own windows property handlers directly to do that in a way that isn't somewhat hacky. That's really the ultimate "fix" for making properties more easily scanned/indexed by Everything in the "correct" way, I just wish it wasn't such a huge pain in the ass to implement. Maybe a windows property handler that just reads values in the same way Everything parses the metadata.efu files would be a good middle ground for making the values visible, and might allow for mirroring them in either a database file or on some other drive than the files themselves if they're on a non-SSD...
However, the more I use it the more I just wish there was a feature to "import" data from metadata.efu files directly into the core database for that property so that it would be remembered if the file moved/renamed (but, if needed, invalidated on content changes), but I think I may just need to return to the idea of building my own windows property handlers directly to do that in a way that isn't somewhat hacky. That's really the ultimate "fix" for making properties more easily scanned/indexed by Everything in the "correct" way, I just wish it wasn't such a huge pain in the ass to implement. Maybe a windows property handler that just reads values in the same way Everything parses the metadata.efu files would be a good middle ground for making the values visible, and might allow for mirroring them in either a database file or on some other drive than the files themselves if they're on a non-SSD...
Re: Does index journal logging continue when Everything runs as a service with no GUI instance open?
I'd missed the previous discussions about it being a future project to do that sort of importing, which is understandable.
Part of the issue is a lot of the properties I'm using are for renaming/deduping my existing files, less so looking through static folders, so any same folder file checking will be less useful than something dynamic. After that comment I decided to work on basically just maintaining my own property database separately (using NTFS file IDs to handle same-drive copies and just coping with reparsing if they change drives) and writing a COM wrapper that will read from it for populating Everything/Windows requests. I don't mind it coming back blank if I haven't yet run the parser on those files, but in plenty of cases that alone will fix most of the issues I have with the current flow.
Part of the issue is a lot of the properties I'm using are for renaming/deduping my existing files, less so looking through static folders, so any same folder file checking will be less useful than something dynamic. After that comment I decided to work on basically just maintaining my own property database separately (using NTFS file IDs to handle same-drive copies and just coping with reparsing if they change drives) and writing a COM wrapper that will read from it for populating Everything/Windows requests. I don't mind it coming back blank if I haven't yet run the parser on those files, but in plenty of cases that alone will fix most of the issues I have with the current flow.