"Virtualized" root directory on Windows (was Re: import/export)

[Bob Rasmussen]

Ken's description of Windows 7's behavior regarding C:\ is accurate as far 
as it goes. I would add:

1) It applies in some cases to Vista, Windows 8 (and 8.1) and Server 2012 
also;

2) It depends on the level setting of the UAC (if you don't know that 
abbreviation you need to!);

3) At applies to folders within the "Program files" and "Program files 
(x86)" tree, which is why Anzio and Print Wizard don't try to save 
settings there any more;

4) It varies depending on whether you are running elevated (a.k.a. "Run as 
administrator"), which is different from running as a member of the 
Administrators group;

5) It applies to various kinds of programs, not just console programs;

6) Windows classifies programs into pre-Vista and post-Vista (really 
"post-XP). All this applies only to pre-Vista programs. Programs are by 
default pre-Vista. The developer of a program can make it a post-Vista 
program by compiling it with a "manifest".

7) It may (I don't know) be possible for an end user to set an EXE to be 
post-Vista.

8) When a post-Vista program runs, its attempts to create files or 
directories in the protected locations will fail, with error status 
indicating inadequate permissions.

9) It would probably a good idea for FP to mark its EXE's as post-Vista, 
to avoid confusion.

Hope this helps.

On Fri, 30 May 2014, Kenneth Brody wrote:

> On 5/30/2014 1:34 PM, Nancy Palmquist wrote:
>> You may have trouble writing to C:\ drive.  Windows 7 does not usually
>> allow it.
> [...]
>
> Actually, it's a but more "interesting" than that.
>
> Windows will let (some?) programs create files in a "virtualized" root
> directory, which is in "%LOCALAPPDATA%\VirtualStore".
>
> When a console application tries to create a new file in the root directory,
> it will instead create it in the VirtualStore directory.  When a console
> application tries to read a file from the root directory, it first looks in
> the VirtualStore directory, and if it's there, gets that one.  If not, it
> will get the one from the "real" root directory, if any.
>
> This can lead to, umm... "fun" scenarios, such as two different versions of
> the apparently-same file.
>
> For example, "gvim c:\fppath" will show one file (it exists -- I created is
> as admin long ago), whereas "vim c:\fppath" will show a different one.  The
> command "type \fppath" will show one version, and "cat \fppath" will show
> the other.
>
> I'm not sure how Windows determines which version the program will see, as
> filePro will see the "real" \fppath file.  (It might be that gvim is marked
> as Windows 5.00, whereas filePro is Windows 5.01, but that's just an
> educated guess at this point.)
>
> But, imagine using "vim \fppath" to change where the file points, having
> filePro still using the old path (despite no PF* environment variables
> overriding it), using "type \fppath" to see that nothing changed, only to
> have "vim \fppath" show you the changes you made.  Even more "fun" is when
> you rename "\fppath" to "\fppath.save", and "vim \fppath" still shows the
> file with your changes.  (And, just to top things off, "gvim \fppath" show
> show a blank, "new file".)
>
> -- 
> Kenneth Brody
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>

Regards,
....Bob Rasmussen,   President,   Rasmussen Software, Inc.

personal e-mail: ras at anzio.com
  company e-mail: rsi at anzio.com
           voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
             fax: (US) 503-624-0760
             web: http://www.anzio.com
  street address: Rasmussen Software, Inc.
                  10240 SW Nimbus, Suite L9
                  Portland, OR  97223  USA