On Sun, 8 May 2016, at 14:33, R Smith wrote: > 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. It can't be that simple because I keep sqlite3.exe in a non-system folder, and the behaviour was the same when I just tried an .output & .dump after this command C:\>"C:\Dropbox\CLIpgms\sqlite3.exe" "C:\Users\username\AppData\Roaming\Mozilla\Firefox\Profiles\jlnfgwfo.default\content-prefs.sqlite" (I'm doing this from my normal day-to-day non-admin userid.) I suppose the next possibility is that the sqlite3.dll that is being used isn't the one that I think it is. I've searched the disk for others and although there are some in various other apps' \bin folders etc, none are in places (eg on PATH) where I'd expect sqlite3.exe to be able to find them. And quite a few have in any case been given other names... which makes me wonder if sqlite3.exe might have a range of alternate DLL names it might load. Is there a way to get sqlite3 to say what version of the DLL it's using (if not the DLL's leafname, at least its build version)? > These "protected" folders are, amongst others, c:\; ... Ah, wait a minute, that's not where sqlite3.exe is resident, but it was the 'current directory' when I issued my commands. I tried my test command again having first changed directory to a documentation folder: C:\Dropbox\Notes-files>"C:\Dropbox\CLIpgms\sqlite3.exe" "C:\Users\username\AppData\Roaming\Mozilla\Firefox\Profiles\jlnfgwfo.default\content-prefs.sqlite" ... and this time the output file got written into: C:\Dropbox\Notes-files I've been using scripts to issue CLI commands for years and never hit this problem before. But... > 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. ... doing so using scripting languages with windows-specific builds, so maybe they've had that manifest thing. Having said that, my scripts would normally use full paths for every file they specify, and I only hit this redirection problem because I was experimenting with sqlite3.exe by hand. This doesn't (or does it?) explain why .output "C:\a\valid\path\file.txt" doesn't work, though. Why would sqlite3 decide that this meant an unpathed file named "avalidpathfile.txt" ? -- Jeremy Nicoll - my opinions are my own.
