Hi again, yeah I know many people with large note data bases, mainly due to videos roughly between 100MB and 500MB, its too much above to sync due to slag.
My WA files are over 1GB, the combine go the iPad copies more raised all this to over 215Gb and going strong , 210GB is in the preview section., this is all in the USER/LIB/Group Containers
View attachment 2407413
In the USER/LIB/Containers I see 27GB now as well!
View attachment 2407414
I can share what I did and that may address that 1.4GB -WAL file. I also forgot to mention I only know how to fix this from the command line (i.e. running commands in Terminal).
The issue I found with the sqlite database used by Notes is that (at least on my versions of macOS) the OS never closes the database and so sqlite's cleanup routine never runs. The cause of this is that even when you close Notes, "accountsd" keeps Notes' sqlite database open.
You can verify this by closing Notes and running the following commands in Terminal:
cd 'Library/Group Containers/group.com.apple.notes'
fuser NoteStore.sqlite-wal
If the "fuser" command comes back with a number next the filename, that is the PID (process ID) of the process still holding the file open. On my systems that is "accountsd". You can verify this with:
ps -fp [PID] where [PID] is the number listed by the above fuser command.
Then you have to kill that program and run the sqlite vacuum command on the database. Before you do the below, I would close all applications (including and especially Notes) and make sure I had a full up-to-date backup of my entire user folder. At the very least, have a backup of your entire group.com.apple.notes folder.
With the above in mind, these are the commands to run in Terminal
kill -HUP [PID]
ps -fp [PID]
fuser NoteStore.sqlite-wal
sqlite3 NoteStore.sqlite 'vacuum;'
The first command kills "accountsd" with the Hangup signal. "accountsd" blocks regular terminate signals. The second command verifies that the "accountsd" process that was holding the database open has actually been killed. If that "accounts" persists or another process is still holding the database open, the last command will not be effective. For the same reason the third command just verifies that nothing else has grabbed hold of the WAL file in the meantime. It should come back with just the filename and no numbers next to it. The last command is what does the work: it tells sqlite3 to open the whole database, rebuild it, and exit. The WAL file should be 0 bytes in size after that.
Note in the above I intentionally used just "NoteStore.sqlite" in the "sqlite3" command and "NoteStore.sqlite-wal" in the "fuser" command above that. In the "fuser" case, I am looking to see what process is holding that specific file open. In the "sqlite3" command, I am telling it to open the database.
After you run those commands, you can restart Notes to see if it still works and all your notes are there. However, since you killed "accountsd", you might want to logout and login again. The system will have restarted "accountsd" automatically after you killed it but I like to err on the safe side when its someone else's system and I am not 100% sure what Apple is doing under the hood.
I say that in the context with again the warning that the above is fairly technically and potentially corrupt your database if something goes wrong. Again, recommending backups before proceeding.
Finally, given the size and unrelenting growth in your Notes database, I would not be surprised if there are other issues there (e.g. corruption outside the sqlite database component). I do not expect the above to fix those issues. Just the relatively large size of that one WAL file.
If you do give the above a try, let us know how it goes.
