I am interested in implementing something that could best be described
as a .plan file that writes itself upon each access. i.e… "type
..plan" would always print, say, the current time. I can think of
about a half-dozen ways to do this in Linux, most of which make use of
the fact that .plan can be a symlink to items in /proc or /dev. I am
stumped as to how to do this under Windows, though.

I am using Win XP w/ NTFS. Portability would be a plus, but is not
mandatory. An approach that requires no daemon/service would also be
preferred. The documentation that shipped w/ my copy of VS.NET
mentions reparse points, but only vaguely mentions the file system
filters with which they interact. Is there an existing fsf that
filters a certain set of reparse point tags back through a
user-defined program? Reparse points certainly look like an elegant
solution for my needs, but spending $1000 for the IFSKit and writing a
kernel-mode driver just to autogenerate a .plan file seems very much
over-the-top. The only alternative that I've come up with so far is
to hijack/detour the system open calls to do something funny whenever
my .plan file is the target. This seems like a pretty hacktastic
approach, though.

This seems like a reasonable task, so I'm very frustrated with myself
for being unable to find elegant solutions. I must be missing
something. I would be most grateful for some advice on this topic.

Thanks in advance,
hatespyware

I think you've exhausted your options there. If you were willing to have the
..plan file accessible only through Explorer, you could write a shell
extension. But if you truly want to be able to access this file as an actual
file, it's an IFS kit job (or, as you say, a kernel-mode hack).

What would go into this file? Any reason why you can't write a service which
emits a real file every time it needs updating?

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

"anon luker" <hatespyware@yahoo.com> wrote in message
news:534d31a2.0401060219.361fe6ac@posting.google.c om...

The problem with writing a service that emits the file upon update is
that I didn't see any way to have that service trigger upon file
access (without using reparse points and a fsf filter or hijacking the
api). The reason I used .plan as an example was because it is an
example of a file that is accessed by many existing programs (like
finger), shell scripts, dynamic web pages, etc. Would your concept of
an emitting service preserve compatibility with this large existing
software base?

I really appreciate your input on this, since I firmly believe that
there should be a simple way to do this. It is possible in about two
lines of perl under Linux (with a mknod fifo). Could it really be so
tough under Windows?
Any further comment would be warmly welcomed.

Thanks in advance,
hatespyware

"Tim Robinson" <tim.at.gaat.freeserve.co.uk@invalid.com> wrote in message news:<btevgm$6fqb1$1@ID-103400.news.uni-berlin.de>...

My point was, how often does the information in the file need to be updated?
Depending on this, you could rewrite the file each time it needs to be
updated, not each time it is accessed.

I can't think of any way of implementing an intelligent file like this on
Windows without writing your own FSD or doing some heavyweight API or system
call hooking.

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

"anon luker" <hatespyware@yahoo.com> wrote in message
news:534d31a2.0401070219.304416ff@posting.google.c om...