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/
Why sqlite3 temp files were renamed 'etilqs_*' (2006)
61–70 of 146 posts
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#62Somewhat 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
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#63I have a related story: Around the year 2000 I was working operations in the NOC for WebTV (then owned by Microsoft). For those who don't know, WebTV was a little set-top box with a modem which would dial up on demand and provide a very basic web/chat/email experience on the TV. The box would call a 1800 number to figure out its own phone number, then re-dial on a local toll-free number with a local sub-contracted IS…
The same year I was working on various online music stores using Microsoft's Windows Media DRM. This would cause a licensing window to pop up in Media Player all the time when the license was missing or expired for someone's music. We would get various complaints emailed to us, and being head developer sometimes the thornier ones would end up in my inbox, and my friendly ass would be kind enough to reply and try to figure them out.
One time one of the senior execs was walking past my screen and peered over my shoulder to read a new email which said "EVERY MORNING YOU ARE ON MY COMPUTER GET OFF MY COMPUTER!!!". The exec leaned over, typed "GO FUCK YOURSELF" and hit reply.
The benefits of being the boss...
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#64Earlier quoted context omitted.
> 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.
I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#65Somewhat 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 us…
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#66Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#67The relevant snippet: /* ** Temporary files are named starting with this prefix followed by 16 random ** alphanumeric characters, and no file extension. They are stored in the ** OS's standard temporary file directory, and are deleted prior to exit. ** If sqlite is being embedded in another program, you may wish to change the ** prefix to reflect your program's name, so that if your program exits ** prematurely, old…
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#68I have a related story: Around the year 2000 I was working operations in the NOC for WebTV (then owned by Microsoft). For those who don't know, WebTV was a little set-top box with a modem which would dial up on demand and provide a very basic web/chat/email experience on the TV. The box would call a 1800 number to figure out its own phone number, then re-dial on a local toll-free number with a local sub-contracted IS…
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#69Earlier quoted context omitted.
I knew two guys long long ago that used to circumvent the per user disk quota on shared machines, which was tiny and not conducive to power users. One found a deep dark corner of the file system, and used it to hold binaries the rest of us used. I think his idea was that if it wasn’t for personal gain it was easier to answer difficult questions, which at some point came up and he got a pass, since it would take more…
> I don’t recall how this worked Unlinking files reduces their reference count. Once the reference count reaches zero the file is considered deleted and the space can be reclaimed. Every open file descriptor and hard link increases a file's reference count. So if you've got a file descriptor open on a file in a background task (daemon, nohup, screen, etc) and unlink it with rm or something the file's reference count…
Someone on my company thought it good to launch background process from within a cron, and start it with `&ˋ at the end, so that it detached from the cron and goes as child to init .
Right, but the program opens std out and dumps its output in it. Guess what, the fd handling the std out ends up in a temp file which is deleted by cron, but still held by the program.
I ended up with a full / in all production servers, with no culprit when running ˋdu`. Only running ˋlsof |grep deleted` did I find these huge temporary files.
Killing the process and switching to a saner systemd service was the savior.
Re: Why sqlite3 temp files were renamed 'etilqs_*' (2006)
#70Earlier quoted context omitted.
> 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.
I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?