2006-10-31: The default prefix used to be "sqlite_". But then Mcafee started using SQLite in their anti-virus product and it started putting files with the "sqlite" name in the c:/temp folder.
This annoyed many windows users. Those users would then do a Google search for "sqlite", find the telephone numbers of the developers and call to wake them up at night and complain.
For this reason, the default name prefix is changed to be "sqlite" spelled backwards. So the temp files are still identified, but anybody smart enough to figure out the code is also likely smart enough to know that calling the developer will not help get rid of the file.
Looks like most links are about antivirus software or Firefox. So it does seem to be working; people are getting pointed to the buggy application code actually causing their problem and not the SQLite project itself
Thanks for this, I was wondering why people would care so much about these files that they go and complain. Reading through these forum questions, looks like most people are trying to free up disk space by clearing temp files, but the SQLite ones can't be deleted - because they are in use and locked - which causes confusion.
while I sneer at the unwashed masses clearing temp stuff by hand in 2024, I'm in the same boat trying to declutter stuff in my Mozilla/Thunderbird profiles :( ...
Several lifetimes ago I was looking at a Solaris server with very limited available space on the root partition and realized that someone had deleted the kernel file, presumably trying to solve the same problem.
Similar to how Daniel Stenberg (`curl` author) gets complain e-mails unrelated to `curl`, because his address end up being in the license or credits screen of plenty of software.
> Apparently, people often have problems finding an appropriate address to contact when they have issues with this app.
> This leads a disproportionate amount of them to send emails to me asking for solutions and fixes to their situations.
SQLite's temp file prefix was originally "sqlite_" until McAfee's antivirus started creating temp files in Windows' `c:/temp` folder, frustrating users who then tracked down and called SQLite developers to complain. In response, the prefix was changed to "etilqs_" (SQLite reversed).
I don't think they have a free number. Just people searching the personal phone numbers of developers from somewhere they might have mistakenly posted it.
> But then Mcafee started using SQLite in their anti-virus product and it started putting files with the "sqlite" name in the c:/temp folder. This annoyed many windows users.
Why did it annoy them? I don’t picture most people noticing such things, and in my mental model, almost everyone that would notice such things would know better than to fly off the handle about it. But clearly I’m miscalculating in some way, so I’m curious if anyone can help me to understand.
> I don’t picture most people noticing such things
It doesn’t need to be most people. All it takes is a small number of people annoying you disproportionately (calling in the middle of the night) to precipitate a change.
> and in my mental model, almost everyone that would notice such things would know better than to fly off the handle about it.
Try doing tech support in any serious capacity for any moderately popular piece of consumer software. There are always “power users” who understand enough to poke around but not enough to follow their investigation to the end. As soon as they find the first place in the chain with a contact (email, phone, forum), they’ll contact it and lambast the person on the other end for all their problems. Just ask the curl developer.
> You expect there to be files in the temp directory.
You expect that. These users are savvy enough to shoot themselves in the foot, but not to understand they don’t know how to safely operate a gun. All they know is they’re on low disk space and there’s some large file somewhere they don’t recognise and want to get rid of.
Not to place all the blame on them, though. Many of these users were bitten by a misbehaving application in the past and had to figure out themselves how to fix their problem. Some of them took the opportunity to learn about their operating system, continued to explore and learn, and eventually became programmers. The others became obsessed with optimising their system and transformed into the prime target for malware-riddled “cleaner” apps which do more harm than good.
This is the interface description. It's not the .c file that implements the abstraction. There is lots of code behind this, redundantly implementing the calls using either Win32 or POSIX.
The filesystem APIs for Windows and POSIX have extremely similar semantics when you bridge their superficial differences. I don't think this is as huge an achievement as suggested. Many multiplatform projects have similar wrapper layers. Indeed the FILE* abstraction in the C standard does some of it. (But not sufficient for the functionality that sqlite needs, hence the need for another wrapper.)
That's not a knock on sqlite, I consider it well implemented and one of my favorite libraries I've ever seen, used and studied.
> The filesystem APIs for Windows and POSIX have extremely similar semantics when you bridge their superficial differences.
This is in part because Windows and POSIX are relatives. Windows is (partly) descended from DOS, and DOS 2 deliberately borrowed a lot of ideas from Xenix (Microsoft’s Unix port). And Windows has continued to borrow ideas from POSIX since, e.g. Winsock is heavily based on Berkeley Sockets.
Compare DOS 2+ handle-based IO to CP/M: CP/M treats files as fixed length 128 byte records instead of bytes, you can only read or write a whole record at a time, and a file’s size on disk must be a whole multiple of 128 [0] - that has more in common with mainframe/minicomputer record-oriented IO than Unix-style byte-oriented filesystems
[0] later on, CP/M added an attribute in the directory entry to store how many bytes were valid in the last record of a file; but it wasn’t actually enforced by the filesystem, apps had to set/get the attribute using a separate API, a lot of apps just ignored it, and even for those who did try to use it, two completely opposite conventions of how to use it coexisted
Yeah, but that is the abstraction. The associated .c files are not the abstraction, because they could be implemented any number of different ways, and it would still be the same abstraction.
It's incredible that even the header file is around 200 LOC. For state-of-the-art, very performant database, I would have thought that all manner of Os-specific IO api's would have to be used.
I don't find it that remarkable. They are function signatures for open, close, read, write, a few locking operations... The signatures for the same operations on both Win32 and POSIX look extremely similar to this. These are fairly "obvious", most multiplatform code written in C has something pretty close to this.
The dividends of damn near everyone who still matters copying Unix and developing similar ideas about subdirectories and filenames and so on.
There's still differences between Windows and Everything Else, but it's easier to ignore them now that, for example, all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored.
> all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored.
not quite true. The classic flat OS/360 filesystem is still heavily used on IBM mainframes. Of course, probably your app will never run on a mainframe, and if it does, it will probably run either under z/Linux or the z/OS UNIX filesystem (zFS). But there is still a lot of actively supported in-production software which does, since born-on-the-mainframe apps mostly use the classic filesystem and the POSIX file API is mainly used by apps ported from elsewhere
Antivirus products are worse than viruses. Change my mind.
(AV hogs CPU, RAM, disk, and network resources. AV comes with their own exploitable vulnerabilities, often running in kernel mode. AV has their own zero-days and zero-click exploits.)
Counterpoint: I have a very non-technical friend that visited recently, and I was horrified to see that her macbook was full of malware. She casually talked about how someone stole money through her credit card. An AV scan actually found something on the laptop.
The AV industry is, unfortunately, terrible. Also unfortunately, some people really need them. I have no idea how one even gets a virus these days, but it does happen. People really do get infected all the time, and basic security advice that people get is not up to the task.
I’m guessing her OS was very out of date? Because I’m having a hard time imagining how this happens in 2024 with XProtect, Gatekeeper, and Notarization all turned on by default. Non-technical people are unlikely to turn these off.
Scripts (OSX ships with Python, Perl, Bash, Zsh, and I think JS) bypass all of those.
Also I would not be suprised if editing scripts in runtime based apps (like electron) still bypass all of those.
Last I looked at code signing in MacOS it was weaker than Windows in places. With code signing checks enabled in Windows (they are used as a smart screen signal but not required by default) you actually need to sign shell scripts to run them.
Small correction: macOS (it hasn’t been called OS X for close to a decade) hasn’t shipped with Python for a while. It does have a shim at /usr/bin/python3 that when called pops up a GUI to the user telling them they need the Xcode Developer Tools, which if accepted does provide Python.
iOS has always isolated apps from your data. Android has isolated apps from your data more and more with previous Android versions where I think they're finally on a similar level to iOS (where an app doesn't just have full access to your local storage by default and also isn't able to request access to sensitive directories).
I wish desktop OSes had evolved with such a model in mind. There is no reason why a calculator should be capable of reading my downloads folder — in fact, I'd even prefer it if I had to give explicit permission to access my network, Internet included. Maybe software wouldn't be so liberal with data collection if we had started requiring such stringent permissions way back when.
File access for apps is gated behind “special” folder access (like Documents/Downloads/etc, and “full disk access” which is anywhere beyond the common user directories)
It's not profitable to make operating systems secure because that encourages use of cracked software, and such software is where most malware comes from.
About the only protection most third party AV provides is that it so badly cripples computer performance that PCs become incapable of running sophisticated malware
I think it's a relatively consensus viewpoint in the security industry that AV products are worse than no AV product. I don't think that makes them worse than viruses, though.
The AV our company uses regularly pops up obnoxious warnings about things that are benign. This trains people to click through warnings without reading them (on any product).
Is the consensus that third-party AV is worse than no AV, or that any AV (including Windows Defender) is worse than no AV?
In the corperate security "industry", anti-virus use is always recommended and required. The more invasive, buggy and annoying for users the better the AV probably is /s
Dev Drive isn't because Defender is so bad but because Dev behavior can look like malicious behavior. Creating a bunch of random executables, connecting to running processes, decompiling files. Stuff that would be malicious behavior from normal user but normal for a dev.
I could be wrong but I don’t believe that even these days anti viruses look at behavioral patterns to identify viruses. They look for signatures of running executables to match malicious patterns in their database. Instead dev drives recommendations are because of performance. There’s substantial overhead & dev patterns, particularly for native code like C/C++/Rust etc, create a lot of intermediary files as part of the build and AV can cause a slowdown. Traditionally the advice for Windows devs was to turn off Defender or exclude your project folders but maybe there was a reason dev drives were still beneficial (maybe it can avoid even more work by working at a drive level).
AV Comparatives does testing every few months of performance impact of various AV software and Defender has never scored great there. Third party AV options have always done better while having the same or better scores in protection tests.
I'm not familiar with AV Comparatives. Do they have any incentives that might influence this result? Offhand, it seems like if Windows Defender is actually the right choice for basically everyone, they wouldn't have any reason to exist, so I can't help but wonder if that would affect their reporting.
They claim to be independent and I've never gotten the sense that any specific AV product is favored in their testing. I realize they could be biased or taking money while pretending they're not, but that's a tough thing to prove one way or the other.
I can say for sure though that Defender at times has a noticeable performance impact. That's why years ago I went looking for performance comparisons in the first place.
Fair enough! I don't pretend to have any expertise in this area, so I mostly was surprised to hear an analysis so contrary to what I've always heard to be the case. I could totally imagine that if there are others like me who just trust what they've heard, over time the narrative of "just use Defender" might become self-sustaining even if the status quo changes, so maybe this is a sign that I should look into things a bit more carefully next time I find myself using Windows.
Even defender is dumb. When you control the OS, which (in the default setup) has exclusive control of all disk reads and writes, you can be sure that if you wrote a virus-free file to disk, then it will be virus-free when you go to read the disk again.
So, why are we doing scan-on-read (with substantial performance overhead) when we should instead be doing scan-on-write (when scanning can, in most cases, be done in idle CPU cycles)?
1) virus database gets updated, what was written virus-free with the previous database may not be virus-free on the current database.
2) removable storage devices
3) the system drive is not controlled during reboots
You could imagine building a system that tracks which files we wrote and with which virus database version, which resets things to be scanned across reboots and virus database updates, and has exceptions for removable devices and so on, but it screams "attack surface"...
Network share, the possibility that a client wrote files while the AV software was disabled, etc
I always felt the same way about daily/weekly scans. How would anything get there if your client, server, etc all have AV? At that point it probably wouldn't be caught anyway.
My comment will not aim to change your mind, but I felt the need to make my case:
I used to work for an AV vendor. I'm quite familiar with its internals. I used to look at some C++ and disassembled malware samples. I'm technically skilled for that kind of reverse engineering.
The engine is so lightweight and optimized that other vendors license it.
It's so lightweight that those underspec'd bank ATM machines you use on the streets with the unfortunate Windows XP or earlier will use that AV with nearly zero performance impact.
> AV hogs CPU, RAM, disk, and network resources.
I hear you, but this is not the case with the AV vendor I used to work for. Years after leaving the company, I still pay for my license (at a legacy discount of course).
Actually, one of the reasons I pay for my license is precisely computer performance. Windows Defender has some BS file indexer[0] that clogs the SSD with 100% continued usage. I just dread it. This bug still remains since the days of Windows 7.
Once you get a proper AV product in your computer, Windows Defender steps down. Bug fixed by myself. Done deal.
The other reason is peace of mind: Windows Defender is not a real security product. I know the protection capabilities of the AV product I licensed. I'm not a complete idiot using my computer, and yet, even I prefer to have it installed and paid for.
It triggers me people saying Windows Defender is enough. It's quite irresponsible. People haven't seen half the crap I've seen. Windows Defender is a little weak kitten compared to the beasts' proper AV products are.
I'm not saying buy the one I use. All I ask is that people buy a lightweight one that has been properly tested by an unbiased third party like AVTest or Virus Bulletin (look for their VB100 100% Detection award).
> AV comes with their own exploitable vulnerabilities, often running in kernel mode. AV has their own zero-days and zero-click exploits.)
As Windows Defender does. Remember, if you don't have any AV product, you have Windows Defender.
I feel that you made a moot point, as every software under the sun comes with vulnerabilities (whether zero-day or known).
The issue for me is privacy, practically all AV are root level spyware, you don't know what are they sending or how, EULA are nightmarish.
They can send logs, files to outside server because so, the code is not available or even opt out of diagnostics.
They monitor browser data and send it to outside servers.
For paid one lets look for EULA (that one mentioned above with VB100 100% Detection )
eset
https://help.eset.com/eav/18/en-US/eula.html
>b) Forwarding of infiltrations and information to the Provider. The Software contains functions which collect samples of computer viruses and other malicious computer programs and suspicious, problematic, potentially unwanted or potentially unsafe objects such as files, URLs, IP packets and ethernet frames ("Infiltrations") and then send them to the Provider, including but not limited to information about the installation process, the Computer and/or the platform on which the Software is installed and, information about the operations and functionality of the Software ("Information"). The Information and Infiltrations may contain data (including randomly or accidentally obtained personal data) about the End User or other users of the Computer on which the Software is installed, and files affected by Infiltrations with associated metadata
...
>For the purpose of this Agreement, it is necessary to collect, process and store data enabling the Provider to identify You in compliance with Privacy Policy
Ive discovered outdated viruses on old backup media that were quickly picked up by AV; new threats aside, old well known threats can still be dangerous if you're not expecting them
> Apple-maintained antivirus system called XProtect which works great
Earlier this year it began detecting Apple-distributed iOS simulator bundles as malware and deleted those [0]. This was a major headache for several days as different headless CI systems developed the problem; we could not figure out how to get a 'good' version of XProtect installed in-place and ended up removing and rebuilding machines.
I don't see any way you can possibly justify that claim. So you're saying the deliberately hostile software, which will cause damage if you install it, is somehow better than the software which can accidentally damage your computer? Even if AV is dangerous 99.999999% of the time (which I think is a bold claim), it would still be better than something which is malicious 100% of the time.
Also I note that half of your argument basically boils down to "it has vulnerabilities". But as bad as that is, it's still not as bad as being exploited. This argument is like saying "being immunocompromised is worse than actually having a deadly illness". It makes no sense.
> Even if AV is dangerous 99.999999% of the time (which I think is a bold claim), it would still be better than something which is malicious 100% of the time.
You are missing the fact that you are supposed to run the AV software 100% of the time, while you are unlikely to ever download a malicious software, let alone execute it with all kinds of countermeasures, such as code signing, in place these days.
> Also I note that half of your argument basically boils down to "it has vulnerabilities". But as bad as that is, it's still not as bad as being exploited.
The point is that it increases your risk of being exploited. With an AV installed there's a lot more code running with extremely high privileges that malware can possibly exploit. While this may be a risk you are willing to take, AV softwares do undoubtedly increase your attack surface and have a history of being exploited.
2006-10-31: The default prefix used to be "sqlite_". But then Mcafee started using SQLite in their anti-virus product and it started putting files with the "sqlite" name in the c:/temp folder. This annoyed many windows users. Those users would then do a Google search for "sqlite", find the telephone numbers of the developers and call to wake them up at night and complain. For this reason, the default name prefix is changed to be "sqlite" spelled backwards. So the temp files are still identified, but anybody smart enough to figure out the code is also likely smart enough to know that calling the developer will not help get rid of the file.