Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why sqlite3 temp files were renamed 'etilqs_*' (2006)

github.com

Post reply on HN
Print view View original

21–30 of 146 posts

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#21

Post by deaddodo »

endisneigh wrote: post #4

Somewhat related - I’m very very curious to hear a detailed account of someone who uses SQLite for a production app with high traffic. For the embedded use case I think it’s a slam dunk, but there are many interesting use cases for server side but they all seem to be toyish. The locking behavior of SQLite is somewhat problematic unless you use WAL and even then not perfect

There are plenty of use cases of SQLite being used in production servers, usually for cache locality of small datasets (think more complex read-focused Redis use cases) or for direct data operations (transforms, for instance).

That being said; even if it weren't usable in a web service space, does that make it any less reasonable of a database? That whole mentality sounds like a web developer centric one. Berkeley DB was used for decades for application and system databases, a field that SQLite largely replaced it in. And one that MySQL, Postgres, Oracle, etc are generally completely unsuited for. It's the same reason Microsoft offered MS Access for so long alongside MSSQL, until MSSQL had it's own decent embeddable option to deprecate it.

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#22

Post by ajsnigrutin »

sedatk wrote: post #14
pronoiac wrote: post #5

Looks like the line numbers were lost: https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14... It's because McAfee started using SQLite, angry users would stumble upon the files, do a minimum of searching or thinking, and be furious at SQLite developers.

I wonder why users were angry about some files in their temp folder. Did McAfee fail to cleanup those files, or were they too big? Edit: more information here: https://www2.sqlite.org/cvstrac/wiki?p=McafeeProblem Apparently, McAfee kept those files locked when it was using them, so the files couldn't be deleted and people got angry that they couldn't clean them up. Sounds like a loud minority to me.

It's a good thing, that there's a clear instructional video on how to remove McAffee antivirus from your computer then:

https://www.youtube.com/watch?v=bKgf5PaBzyg

(yes, it's the funny one)

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#23

Post by arp242 »

pronoiac wrote: post #5

Looks like the line numbers were lost: https://github.com/mackyle/sqlite/blob/18cf47156abe94255ae14... It's because McAfee started using SQLite, angry users would stumble upon the files, do a minimum of searching or thinking, and be furious at SQLite developers.

Daniel Stenberg has also gotten some ... interesting ... emails because people found the curl license somewhere and assumed he was responsible for $stuff.

https://daniel.haxx.se/blog/2016/01/11/tales-from-my-inbox-p...

https://daniel.haxx.se/blog/2016/01/19/subject-urgent-warnin...

https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-...

https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#24

Post by hakfoo »

endisneigh wrote: post #4

Somewhat related - I’m very very curious to hear a detailed account of someone who uses SQLite for a production app with high traffic. For the embedded use case I think it’s a slam dunk, but there are many interesting use cases for server side but they all seem to be toyish. The locking behavior of SQLite is somewhat problematic unless you use WAL and even then not perfect

I've been pushing to try SQLite as a "sacrificial memozation." Basically we have two tasks separated by 5-10 days. When we do the first task, we calculate a bunch of information as a "side effect". At the second task, we don't have that information and trying to reconstruct it without the original context is very slow, because a lot of it is dependent on temporal state-- what was happening 5-10 days ago.

The other use case I'm eager to explore is as persistence of status data in a long-running process. Occasionally the task blows up halfway and although we can recover the functional changes, we lose the reporting data for the original run. If we save it in a SQLite database instead of just in-script data structures, we don't have to try to reverse engineer it anymore.

In both cases, I like the idea of "everything's one file and we nuke it when we're done" rather than "deal with the hostile operations team to spin up MySQL infrastructure."

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#25

Post by deaddodo »

sltkr wrote: post #13
ShadowBanThis01 wrote: post #8

Love it. Too bad there aren't enough Mac users to prompt a similar backlash against Macs littering every computer they visit on the network with .DS_Store and other turds.

This isn't remotely comparable. Those .DS_Store files are created in arbitrary directories by the Apple file manager or something. The SQLite temp files are created in the OS-specific temporary directory (e.g. C:/Users/username/AppData/Local/Temp or whatever on Windows) which is specifically intended for that purpose. SQLite isn't doing anything wrong; that's where it's supposed to store temporary data that doesn't f…

> Those .DS_Store files are created in arbitrary directories by the Apple file manager or something.

.DS_Store files come from Apple's file systems containing a separate data and resource fork. APFS can natively store the contents, but for foreign file systems/network shares, a .DS_Store file is created to store those attributes.

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#28

Post by thakoppno »

banana_giraffe wrote: post #18
sedatk wrote: post #14

Earlier quoted context omitted.

I wonder why users were angry about some files in their temp folder. Did McAfee fail to cleanup those files, or were they too big? Edit: more information here: https://www2.sqlite.org/cvstrac/wiki?p=McafeeProblem Apparently, McAfee kept those files locked when it was using them, so the files couldn't be deleted and people got angry that they couldn't clean them up. Sounds like a loud minority to me.

There's some level of power user that will try to fix things, not understand what's going on, and yell at the world when they break things further. I used to have a popular freely available 3rd party DLL that was included in lots of software packages. Because I was silly, it had my email address in the metadata that'd show up if you clicked "Properties" in Explorer. I'd get plenty of emails from random people asking…

> There's some level of power user that will try to fix things, not understand what's going on, and yell at the world when they break things further.

That appears to me to be quite like a Chesterton fence. Everyone encounters these eventually.

https://en.m.wiktionary.org/wiki/Chesterton%27s_fence

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#29

Post by codedokode »

lopkeny12ko wrote: post #27
codedokode wrote: post #26

This is a bad choice, I wouldn't understand that it needs to be read backwards. Why not use process's executable name instead?

Did you even open the link? Human readability was not a goal, in fact quite the opposite.

I meant use the name of the program that embeds SQLite, for example, McAfee, Google Chrome etc. This way the user could easily understand which program has created the files.

Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)

#30

Post by gumby »

ShadowBanThis01 wrote: post #8

Love it. Too bad there aren't enough Mac users to prompt a similar backlash against Macs littering every computer they visit on the network with .DS_Store and other turds.

You mean like those thumbs.db files windows leaves on every computer they visit on the network?
Post reply on HN