Actually, I assumed SQLite made the duplicates / alternates, it may well have been the anti-virus doing it. I doubt anything else had a motive though.
On 2015-04-22 06:20 PM, R.Smith wrote: > > > On 2015-04-22 05:56 PM, Simon Slavin wrote: >> On 22 Apr 2015, at 4:46pm, Michael Stephenson <domehead100 at gmail.com> >> wrote: >> >>> Simon, if the data in the database is sensitive, could you encrypt >>> the database (ala something like https://www.zetetic.net/sqlcipher/)? >> Unfortunately, this doesn't help. I'm not concerned with the >> database file itself. I know exactly what that's called, and I can >> check it has been correctly deleted. I'm concerned with the data in >> several external files that SQLite creates and deletes as it does its >> work. Some of those would contain unencrypted data. And some of >> them have unpredictable names, or, at least since the filenames are >> not documented they may change in future versions of SQLite. >> >> You have made me realise, however, that a nice attack against >> encrypted SQLite databases might be to crash a SQLite application >> while it's processing and examine any journal files, shared memory >> file and temporary index files. It might be interesting to review >> the various encryption systems widely available for SQLite and figure >> out which of them would be vulnerable to such an attack. > > I've experienced some things you may need to take note of. I've had > SQLite files created and amended on a Windows system with an > anti-virus that held on to the journal files making them either > read-only or not-deletable. (I did not check nor cared which, my > solution was to remove the anti-virus). The point is that when this > happened, SQLite made duplicate/alternate journal files with what > seemed to be random hashes in the name near the end. (Who knows if > they were random, hashes all look random). > > These files were often empty (0-byte-length) after a session but > whatever writings went on in there certainly still reflected on the > disk surface. > > Maybe a dev can shed more light - I do not know the mechanism for this > - but I do know it was easy to find and remove them for me, they > always had the same base name as the DB file with some extra bits > (what seemed like a hash) sprinkled on at the end and terminating in > the usual journal extensions. > > This was not a great concern for me so my observations/research is > full of holes and unknowns, but I know that it happened. > > Good luck. > Ryan > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
