file contexts - question

NTFSD
1

Hello, I’d like to implement file contexts (in memory, no need to save them
after rebooting) - it should be created when a file will be open (for the
first time) and even if I close the file, move it to the other location and
open again then I’d like to get the same file context I’ve created for the
first open. I cannot rely on hashing of filename checksum (because the file
can change its location) - maybe I could use FileId, but I’ve read in old
messages if I defrag a drive on FAT32, FileIDs can be changed (maybe I could
monitor the changing? but i’m not sure, it may not be easy) - or is there
any other method ?

This feature will be implemented in minifilter, so how guys will you do that
? :slight_smile:

thanks,
Benn

Express yourself instantly with MSN Messenger! Download today it’s FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2

If you can restrict yourself to Windows Vista, you’ll be able to use
filter manager support for file context. Earlier versions only have
stream contexts, however.

For FAT, though, there is no support for multiple streams and thus the
stream context IS a file context. Thus, you could use the file ID (in
NTFS) to create those per-file contexts. If you are concerned about
network file systems, you should be aware that file IDs may not map
one-to-one (this used to be true with CIFS, for example, but given that
it does change over time this might not be the case at the moment). We
had to fix this by including code on both the server and client side to
retrieve the file ID across the network. In our DMK tool we write a
GUID inside the file so that we can uniquely detect the file, even
across the network, even with aliasing and hard links and short names
and open by file ID or open by object ID…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Benn H
Sent: Wednesday, October 19, 2005 4:45 AM
To: ntfsd redirect
Subject: [ntfsd] file contexts - question

Hello, I’d like to implement file contexts (in memory, no need to save
them
after rebooting) - it should be created when a file will be open (for
the
first time) and even if I close the file, move it to the other location
and
open again then I’d like to get the same file context I’ve created for
the
first open. I cannot rely on hashing of filename checksum (because the
file
can change its location) - maybe I could use FileId, but I’ve read in
old
messages if I defrag a drive on FAT32, FileIDs can be changed (maybe I
could
monitor the changing? but i’m not sure, it may not be easy) - or is
there
any other method ?

This feature will be implemented in minifilter, so how guys will you do
that
? :slight_smile:

thanks,
Benn

Express yourself instantly with MSN Messenger! Download today it’s FREE!

http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

>

retrieve the file ID across the network. In our DMK tool we write a
GUID inside the file so that we can uniquely detect the file, even
across the network, even with aliasing and hard links and short names
and open by file ID or open by object ID…

When you write a GUID into every file, do you have to do a dance with all
the IRP’s
to make sure no one else sees it? I mean reads, query_information etc.
etc will all need to be doctored so that they don’t see this additional
information written
in the file. Is this true? or am I missing something?

4

You’ve got it - that’s exactly what you have to do. Much the same way
NTFS hides its meta-data from the user’s we hide our meta data as well.
Logically, it is a stackable or layered file system.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of faras namus
Sent: Friday, October 21, 2005 10:36 PM
To: ntfsd redirect
Subject: Re: [ntfsd] file contexts - question

retrieve the file ID across the network. In our DMK tool we
write a
GUID inside the file so that we can uniquely detect the file,
even
across the network, even with aliasing and hard links and short
names
and open by file ID or open by object ID…

When you write a GUID into every file, do you have to do a dance with
all the IRP’s

to make sure no one else sees it? I mean reads, query_information etc.

etc will all need to be doctored so that they don’t see this additional
information written

in the file. Is this true? or am I missing something?

— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com

5

> When you write a GUID into every file, do you have to

do a dance with all the IRP’s

In such thing like DMK (a layered file system), you must dance
with all the IRPs anyway.

L.

6

Ladislav,
I understand that. Was curious how they maintained the GUID.
Tony,
If you store a GUID into each file, how easy or difficult is it to
uninstall a driver built using DMK? I would imagine it would involve lot of
IO, because now you would need to go visit each file and remove the GUID’s?
Thanks

On 10/22/05, Ladislav Zezula wrote:
>
> > When you write a GUID into every file, do you have to
> > do a dance with all the IRP’s
> In such thing like DMK (a layered file system), you must dance
> with all the IRPs anyway.
> L.
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

> If you store a GUID into each file, how easy or difficult

is it to uninstall a driver built using DMK? I would imagine
it would involve lot of IO, because now you would need to
go visit each file and remove the GUID’s?

The question is more philosophic than related to DMK -
imagine you have an encryption software active and some files
encrypted. Now what to do in the uninstaller. Will you decide
to decrypt the files to make them usable after the software is gone ?

The answer is - this is up to you. You may include
an “I want to decrypt my files” checkbox in the uninstaller,
if you want/need to.

L.

8

I am thinking of building another kind of a driver using the DMK which is
not an encryption or compression driver, but can still leverage quite a lot
of stuff in the DMK. One of the requirements in it is instantenous
install/uninstall. The other key requirement is not to muck around with
files on
disk.

On 10/24/05, Ladislav Zezula wrote:
>
> > If you store a GUID into each file, how easy or difficult
> > is it to uninstall a driver built using DMK? I would imagine
> > it would involve lot of IO, because now you would need to
> > go visit each file and remove the GUID’s?
> The question is more philosophic than related to DMK -
> imagine you have an encryption software active and some files
> encrypted. Now what to do in the uninstaller. Will you decide
> to decrypt the files to make them usable after the software is gone ?
> The answer is - this is up to you. You may include
> an “I want to decrypt my files” checkbox in the uninstaller,
> if you want/need to.
> L.
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>