The VFS appears mounted in a specific point on the actual filesystem.
There's no problem accessing files outside or inside the VFS.
I have a starkit, for example that implements a launcher for X11 clients
to windows X11 servers.  That starkit is able to, and perfectly well 
does, store session configurations in a file in the 'normal windows
locations $AppData\xlauncer'.

The application can find the top-level of the starkit vfs via the
variable starkit::topdir

See e.g. http://wiki.tcl.tk/4080

for more information and sample code.


Ron.

Joe wrote:
> How does this handle interacting with the filesystem outside the VFS?
> So let's say you have files in the same directory as the starkit  How
> would you access them?  Does it automatically assume you're accessing
> something outside of the starkit unless you specifically say you want
> something in the starkit?  (IIRC that's how jars work in Java)
> 
> Joe
> 
> On Dec 20, 2007 4:39 PM, Ron Fox <fox / nscl.msu.edu> wrote:
>>   Some differentiations:
>> 1.  starpack/starkit technology also supports a separation of the
>> run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
>> in the VFS).    This allows you to split the installer into a system
>> dependent piece (the tclkit) and the application (starkit).  These can
>> be combined to a starpack which is system dependent.
>>
>> 2. Because the starkit part of the system is a full featured filesystem
>> from the Tcl/Tk point of view it's possible to do a few neat things
>> including automatic updating of the contents of the starkit.  The
>> application, as it starts up can ask the world if there are newer
>> versions and, if desired, confirmed by the user..all the application
>> specific caveats you care to apply, can update itself in place.
>>
>> 3. Because the VFS that constitutes starkits is actually a metakit
>> database, updates described above can be done as a transaction which
>> either entirely succeed or entirely fail, but not leave the application
>> in some funky state.
>>
>> 4. Again, because the VFS is a file system, the application can:
>>   - store data (e.g. ordinary help files) and access them as files.
>>   - keep e.g. configuration data allowing for a portable computing env.
>>     (e.g. a web-browser starpack could keep your book marks in its
>>      VFS so you could run around with your browser on a memory stick).
>>
>> 5. Because the starkit is a virtual file system to Tcl/Tk, there's no
>> need to unpack the application into a temp directory for purely scripted
>> apps.. or for apps whose extensions are built into the tclkit.  Only
>> compiled loadable extensions need to be copied out into the host's
>> filesystem so that they host system's dynamic loader can find them.  For
>> large apps this can improve the startup time significantly.
>>
>> Ron.
>>
>>
>>
>> Adam Shelly wrote:
>>> On 12/20/07, Ron Fox <fox / nscl.msu.edu> wrote:
>>>>   Starpacks are executables that
>>>> consist of the intepreter, necessary compiled packages, and a virtual
>>>> file system appended to the back end of the executable that contains the
>>>> script, scripted packages and loadable binaries.
>>>>
>>>>   A similar sort of thing for Ruby might be a _good_ thing.  The
>>>> seminal paper on starpacks and the related starkit (the virtual
>>>> filesystem unbundled from the run-time) is at:
>>>>
>>> Isn't this exactly what rubyscript2exe does?
>>> http://www.erikveen.dds.nl/rubyscript2exe/
>>>
>>
>