Hacker News Reader

Comment by pronoiac | Hacker News Reader

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.

View on HN

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/

I've always wondered if Daniel gets a particular amount of email of this sort because his address includes "haxx"--for someone without tech savvy, it's not all that much of a jump to assume an email that includes something sounding like hacking is the email of the hacker that has attacked them.

Yes, that seems to be the likely explanation at least for the second linked email which closes with:

”Please see attached screen dump for a screen shot of your contact info included in Spotify (or what more likely seems to be a hacked Spotify developed illegally by a third party).”

The last one has to be an elaborate troll. Only a 4chan user would type "RIP Terry A. Davis" anywhere.

Check the ‘apology’ follow up. The person claims to be schizophrenic. Even the apology mail makes no sense and is full of paranoia and read like a group stalking delusion.

What makes it so that only 4chan users would have empathy for the death of other programmers? Terry's death was quite tragic and his work was often discussed in technical circles for it's novelty...despite his eccentricities. Love him or hate him, no human being deserved the circumstances of his life or of his death.

RIP Terry. A. Davis

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 for and sometimes _demanding_ help with software I've never heard of. I'm sure if I had an easy to find website with my name and a forum on it, it'd be full of such angry comments.

> 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

> Sounds like a loud minority to me.

Imagine for a moment the cross section of Windows users that 1) have McAfee running 2) poke around the Windows temp folders and/or run some sort of "cleaner" to "optimize" their system and 3) don't recognize the name "sqlite". I can imagine the exact type of user, peak Dunning-Kruger and utterly insufferable. Even just seeing their e-mails before deleting them would be maddening. I think most people on HN can vividly imagine the sort or remember back when they were that insufferable twat.

I was that person once. I was 12 and couldn't understand why MS-DOS disk maintenance tools shouldn't be used on PC-DOS because obviously repair tools can only fix things

Children really are peak Dunning-Kruger.

That's interesting. Some DOS clones had a different FAT format?

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)

In Linux, these files are unlinked, so they are invisible in the filesystem. It is legal to unlink an active file descriptor, but continue reads/writes to it.

I think that lsof can still see these temporary files; I'm not sure how I first noticed it.

Windows implements a POSIX kernel layer, so perhaps this functionality could be coaxed out of it.

lsof shows “open file handles” which can include deleted files. Can be useful when you have a disk showing tons of usage but you can’t find any big files.

Apparently, recent Windows uses POSIX semantics by default: https://news.ycombinator.com/item?id=23745019

If a file is opened with `FILE_SHARE_DELETE` then it can be deleted while held open. This flag has existed since forever. It's just that unlike Linux this isn't the default, and no developer would think of setting it. I think the only common software I saw using it when I still used Windows was the media player mpv.

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 disk space if we had private copies.

The other was keeping file handles open to deleted files, as you describe. I don’t recall how this worked, but I suspect it involved uncompressing data into a file descriptor, then reading it back. I guess as long as his terminal window was open it was more stable than tmp (he may have also been using screen).

> 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 will decrement but not go to zero. Only when that program closes the file descriptor will the reference count go to zero and the file actually be deleted.

I had an interesting issue with that the other day:

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.

When youtube was flash based that is how flash would save it's cache file for the stream. to save a video you would go looking for what file descriptors were in use and yank them out of I believe /dev/fd and back into the filesystem. On windows the file was visible but locked behind the normal windows file locking shenanigans. To copy locked files on windows I used a program called hobocopy that utilized volume shadow tricks to work around the locks.

Reply on news.ycombinator.com