There is one interesting but little-known way of doing this on Windows NT/2K/XP: file streams.
A file on an NTFS file system can have multiple streams of data. When you refer to the file name by itself, you access the main stream, but you can create arbitrary additional named streams of data. For example, try this:
dir \ > xxx.xxx
dir \windows > xxx.xxx:stream1
If you do this:
more < xxx.xxx
you'll see the root directory. If you do this:
more < xxx.xxx:stream1
you'll see the Windows directory. You can use any string of characters after the colon, and create as many streams as you want. The extra streams do not appear in a directory listing, so users do not see them. The streams get carried with the file when it is copied, and are removed when the main file is deleted.
Many of the built-in cmd commands do not recognize these names, because they parse the names looking for a drive letter, so this doesn't work:
type xxx.xxx:stream1
but anything that uses the standard CreateFile API works. For example, the Cygwin utilities are fine with it:
cat xxx.xxx:stream1
This doesn't solve your problem, because it is Windows-only, but it is something to keep in your toolbox.
···
On Tue, 21 Dec 2004 10:20:33 -0500, Charles Hartman <charles.hartman@conncoll.edu> wrote:
With an earlier app I wanted an external data file and everybody told me to make it internal to the program (the app's resources, on OS X) instead. I couldn't, then. Now with a new app I want to do just that, but I'm not sure *how* to do it!
It's a file of data -- a Python dictionary object, once loaded into memory -- which will grow and change as the app is used; when the app terminates the data ought to be saved with it for next time. In this case I don't want users fiddling with it apart from the app.
What is the right way to do this? (What's the easy way?) Is there a simple method that will work for both Mac and Windows (and Linux)?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.