On 2016/05/08 10:57 AM, Jeremy Nicoll wrote: > I'm using Windows 8.1, 64bit, and yesterday installed the V3.12.02 > 64-bit DLL along with > the 32-bit SQLite tools. > > I was investigating the contents of a logs file created by my antivirus > & firewall package, > which keeps that file in > > C:\Program Files\Emsisoft Internet Security\Logs\logs.db3 > > and thus issued, in a terminal window, the command: > > C:\>sqlite3 "C:\Program Files\Emsisoft Internet Security\Logs\logs.db3" > > When I issued subcommands like .databases .dbinfo .tables > .schema etc I got > what looked like perfectly reasonable results, in the command window. > > I then tried eg > > .output myfile.txt > .dump > > and was perplexed that no "myfile.txt" file was created anywhere obvious > - not in the current > directory (which was just C:\), not in %TEMP%, not in the same directory > as the logs file. I > also tried specifying a full path, eg: > > .output "C:\Users\username\Desktop\JNsqlite3out.txt" > .dump > > and again no file seemed to be produced. Later on I searched the whole > disk looking for > files with the sorts of literal names that I'd used in my tests, and > found them all... in > > C:\Users\username\AppData\Local\VirtualStore > > and oddest of all, there was a file there with a leafname of > > UsersusernameDesktopJNsqlite3out.txt > > > Now I know that C:\Users\username\AppData\Local\VirtualStore is a > Windows file system > virtualisation folder, into which it redirects I/O that would otherwise > have been written to a folder > which requires the program generating it to be running elevated, ie as > an Administrator. But I do > not understand why sqlite3.exe should think I asked for that, unless the > characteristics of the > folder that contained the database file itself are somehow applied to > the .output destination. > > I did later find (in the reply to a question on stackoverflow) that > .output would understand a fully > pathed filename if I enclosed that in single quotes rather than double > quotes, but that's neither > documented anywhere that I could see nor intuitive for a Windows user. > After all, the sqlite3 > command itself has the database's filepath enclosed in double quotes. > > Is all this working-as-designed? Did I fail to find some necessary > documentation? >
You are correct that the Windows virtualization is the cause of this, as you already figured out. The only reason any output would be virtualized is that Windows regards the folder used (or default if none is specified) as one of the "protected" folders. To be clear, this would be the folder in which you have sqlite3.exe running from (and hence the default path where an non-pathed file will want to be created by sqlite3.exe). Not the DB folder or any other. These "protected" folders are, amongst others, c:\; c:\Program Files\; c:\Program Files(x86)\; etc. (And by "c:" I simply mean the OS drive, which may be another drive in your system). There is something sqlite can do to prevent virtualization, which is mainly to include a manifest file in the Windows build, but this would not be cross-platform, so not in the spirit of SQLite. Best is for you to not use any protected folders when doing things (which is a must if you make applications for others), or simply switch off the Windows virtualization - not recommended, but ok for your own personal system. Cheers, Ryan
