Let me guess: the program that created the file, and also the GNU utilities, are not running as administrator.
First, some history. In the days of Windows XP, lots of programs assumed they would always be run as admin, and would write to places like C:\Windows
and C:\Program Files (x86)
with wild abandon. With Vista, Microsoft tried to make fewer people admins, but standard users can't write to those places. They needed those dubious programs to keep working (or else people wouldn't upgrade). So, they introduced a magical feature called UAC virtualization.
Programs running as standard users might think their writes to important locations succeeded, but in reality, Windows squirreled the data away in a per-user location. When those programs look for files in a directory, Windows checks to see whether there are any files in that place's virtual store, and if so, it adds them to the directory listing. (There is equivalent functionality for the Registry.)
It looks like your mail program tried to write to a place under Program Files (x86)
while running as a normal user. The write was redirected, so it didn't actually go to that place. The program can still see it, because Windows is keeping up the illusion for it. Explorer doesn't see it because it announces to the operating system that it's well-behaved and so doesn't need redirection. The command prompt's dir
command isn't a program (it's just a feature of cmd.exe
), so it is also considered "in the know" and so is not shown the compatibility files. ls
is a program that is, evidently, not in the know, so it gets to see the compatibility files.
You'll find your file here:
%LOCALAPPDATA%\VirtualStore\Program Files (x86)\IMAPSize\backup
While poking around in VirtualStore
, you might be surprised at what programs are not well-behaved and need the virtualization safety net.
If you want to stop the redirection, run the program as administrator, or save your backups in a location that you can actually write to without admin privileges.
1The only conspicuous difference I see is that
ls -l
is showing a peculiar number of hardlinks to the "hidden" directories and files... I don't know why that is, nor how a hardlink is even interpreted in NTFS-land. – Xophmeister – 2016-04-01T23:59:37.140...Just to confirm: I can access the data in the "hidden" files, from the command line, using
cat
(another GNU coreutil). Again, however, native Windows tools (e.g.,type
) can't even find the file. – Xophmeister – 2016-04-02T00:08:36.507