database is not saved on shutdown

[scharf]

Hi,

I love everything! I have about 2 million files and it takes a while to index them. If I use Everything 1.2.1.451a the database is saved when I exit everything from the tray icon. But when I shut down windows, the database is *not* saved. That means on startup the database has to be recreated. And that takes a while. It is quite annoying because the indexing takes place while other applications are about to start and it changes the time till all programs are running form 5 min to 20 minutes. I think it has to do with disk seek time. I recently got a Intel ssd drive and there it does not really matter. But with a physical hard drive the indexing after reboot really hurts.

Michael

[scharf]

Hi,

here is the Microsoft help page on shut down. I guess everything is a window application and therefore it should save the database when it gets the WM_ENDSESSION message.

Michael

[void]

"Everything" saves changes to the Everything.db file after WM_QUIT has been received.

Please note that "Everything" does not save changes to the database if you run it in debug mode.

[scharf]

I am not running 1.2.1.451a in debug mode (unless the debug mode is the default).

The database is saved when I exit using the context menu in the task bar but it is *not* saved when I shut down the system.

If I read the Microsoft documentation correctly then WM_QUIT is not called when the system shuts down. In that case WM_ENDSESSION is called. It says in the documentation:

Applications that have unsaved data could save the data to a temporary location and restore it the next time the application starts.

It does not say that WM_QUIT is called in that case.

As I understand it: when the system shuts down it sends a WM_QUERYENDSESSION to all processes. If all processes return TRUE then it will send WM_ENDSESSION to all processes (with the ENDSESSION_CLOSEAPP parameter).
That is when you should save the state. After that the process is terminated and no WM_QUIT is called.

Here are a few forum posts that confirm my understanding:
- Windows doesn't close windows when a user logs off; that's your call
- Terminating Systray Application On Shutdown does not work
- Application termination when user logs off

but maybe I am wrong and I am running everything in debug mode without knowing....

Michael

[wfg]

I've the same problem. Very much files on local and external harddisks and Everything tells me at the first use after booting, that it creates (not updates) the database.
I think there is a second problem: some of my harddisks are "mounted" as subdirectory on drive D:, e.g. d:\_HDEXT\graphics
I've tried to exclude the directory d:\_HDEXT but it seems, that Everything ignore this.

Best regards,
wfg

[void]

Fixed for the next release.

I think there is a second problem: some of my harddisks are "mounted" as subdirectory on drive D:, e.g. d:\_HDEXT\graphics
I've tried to exclude the directory d:\_HDEXT but it seems, that Everything ignore this.

You will need to use the latest alpha release to index volumes mounted to a NTFS folder.

[zzh1989829]

Hi,

I love everything! I have about 2 million files and it takes a while to index them. If I use Everything 1.2.1.451a the database is saved when I exit everything from the tray icon. But when I shut down windows, the database is *not* saved. That means on startup the database has to be recreated. And that takes a while. It is quite annoying because the indexing takes place while other applications are about to start and it changes the time till all programs are running form 5 min to 20 minutes. I think it has to do with disk seek time. I recently got a Intel ssd drive and there it does not really matter. But with a physical hard drive the indexing after reboot really hurts.

Michael

i just figured out a compromise solution :
1. run gpedit.msc
2. select computer configuration -> window settings -> scripts (startup /shutdown ) ->shutdown
3. add a script (filename.bat) which content is "taskkill /f /im everything.exe"

then if you shutdown, at least the database won't lose.
at the same time hoping the author solve this bug.