Hi,
The following are sequence of file operations that
I would like to process them in my encryption filter driver.
All the files in directory c:/a/b/c need to be encrypted
and all the files in c:/x/y/z need to decrypted.
create c:/a/b/c/source.txt
write c:/a/b/c/source.txt
close c:/a/b/c/source.txt
create c:/x/y/z/target.txt
rename c:/a/b/c/source.txt c:/x/y/z/target.txt
delete c:/a/b/c/source.txt
I read the rename operations in OSR’s “Filter Driver
Discussion paper”, which is a very helpful information
regarding “rename” operation. In the above rename
case, it seems to me that my filter driver needs to
create my own IRP to perform a “read” on source.txt
and decrypt the data before creating another IRP to
write target.txt in a decrypted directory. Is this
approach sounds a right one in the filter driver?
If I want to handle “rename c:/a/b/c c:/x/y/x” in my
encryption filter driver, is it doable? Your input is
really appreciated.
Wencheng
Revisit your design. Far too complex. Just return the status that
indicates a move is not possible. Try it with EFS and see what happens when
a file is renamed from an encrypted directory to a plaintext directory and
duplicate it. I think it will probably be an error that forces a program to
use a copy and delete.
What happens if one of the directories is joined or subst’d. A rename won’t
work either.
wrote in message news:xxxxx@ntfsd…
>
>
>
> Hi,
>
> The following are sequence of file operations that
> I would like to process them in my encryption filter driver.
> All the files in directory c:/a/b/c need to be encrypted
> and all the files in c:/x/y/z need to decrypted.
>
> create c:/a/b/c/source.txt
> write c:/a/b/c/source.txt
> close c:/a/b/c/source.txt
> create c:/x/y/z/target.txt
> rename c:/a/b/c/source.txt c:/x/y/z/target.txt
> delete c:/a/b/c/source.txt
>
> I read the rename operations in OSR’s “Filter Driver
> Discussion paper”, which is a very helpful information
> regarding “rename” operation. In the above rename
> case, it seems to me that my filter driver needs to
> create my own IRP to perform a “read” on source.txt
> and decrypt the data before creating another IRP to
> write target.txt in a decrypted directory. Is this
> approach sounds a right one in the filter driver?
> If I want to handle “rename c:/a/b/c c:/x/y/x” in my
> encryption filter driver, is it doable? Your input is
> really appreciated.
>
> Wencheng
>
>
>
>
>
>
Hi David,
Many thanks for your inputs, I will try EFS and see what
happen.
Wencheng
Revisit your design. Far too complex. Just return the status that
indicates a move is not possible. Try it with EFS and see what happens
when a file is renamed from an encrypted directory to a plaintext
directory and duplicate it. I think it will probably be an error that
forces a program to use a copy and delete.
What happens if one of the directories is joined or subst’d. A rename
won’t work either.
wrote in message news:xxxxx@ntfsd…
>>
>>
>>
>> Hi,
>>
>> The following are sequence of file operations that
>> I would like to process them in my encryption filter driver.
>> All the files in directory c:/a/b/c need to be encrypted and
>> all the files in c:/x/y/z need to decrypted.
>>
>> create c:/a/b/c/source.txt
>> write c:/a/b/c/source.txt
>> close c:/a/b/c/source.txt
>> create c:/x/y/z/target.txt
>> rename c:/a/b/c/source.txt c:/x/y/z/target.txt
>> delete c:/a/b/c/source.txt
>>
>> I read the rename operations in OSR’s “Filter Driver
>> Discussion paper”, which is a very helpful information
>> regarding “rename” operation. In the above rename
>> case, it seems to me that my filter driver needs to
>> create my own IRP to perform a “read” on source.txt
>> and decrypt the data before creating another IRP to
>> write target.txt in a decrypted directory. Is this
>> approach sounds a right one in the filter driver?
>> If I want to handle “rename c:/a/b/c c:/x/y/x” in my
>> encryption filter driver, is it doable? Your input is
>> really appreciated.
>>
>> Wencheng
>>
>>
>>
>>
>>
>>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@covad.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi
The error code you are looking for is STATUS_NOT_SAME_DEVICE. This forces a
copy and delete operation instead of a rename, I have been using this for
some time now and it seems to work really well.
Ben Curley
Software Engineer
Data Encryption Systems Ltd.
Tel: +44 (0)1823 352357 (Main)
Tel: +44 (0)1823 358320 (Direct Dial)
Web: http://www.deslock.com
-----Original Message-----
From: xxxxx@covad.net [mailto:xxxxx@covad.net]
Sent: 11 July 2003 23:09
To: File Systems Developers
Cc: xxxxx@yoshimuni.com
Subject: [ntfsd] Re: Rename a file and directory
Hi David,
Many thanks for your inputs, I will try EFS and see what
happen.
Wencheng
Revisit your design. Far too complex. Just return the status that
indicates a move is not possible. Try it with EFS and see what
happens when a file is renamed from an encrypted directory to a
plaintext directory and duplicate it. I think it will probably be an
error that forces a program to use a copy and delete.
What happens if one of the directories is joined or subst’d. A rename
won’t work either.
wrote in message news:xxxxx@ntfsd…
>>
>>
>>
>> Hi,
>>
>> The following are sequence of file operations that
>> I would like to process them in my encryption filter driver.
>> All the files in directory c:/a/b/c need to be encrypted and all the
>> files in c:/x/y/z need to decrypted.
>>
>> create c:/a/b/c/source.txt
>> write c:/a/b/c/source.txt
>> close c:/a/b/c/source.txt
>> create c:/x/y/z/target.txt
>> rename c:/a/b/c/source.txt c:/x/y/z/target.txt
>> delete c:/a/b/c/source.txt
>>
>> I read the rename operations in OSR’s “Filter Driver
>> Discussion paper”, which is a very helpful information
>> regarding “rename” operation. In the above rename
>> case, it seems to me that my filter driver needs to
>> create my own IRP to perform a “read” on source.txt
>> and decrypt the data before creating another IRP to
>> write target.txt in a decrypted directory. Is this
>> approach sounds a right one in the filter driver?
>> If I want to handle “rename c:/a/b/c c:/x/y/x” in my
>> encryption filter driver, is it doable? Your input is
>> really appreciated.
>>
>> Wencheng
>>
>>
>>
>>
>>
>>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@covad.net To
> unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Ben,
Many thanks for the information!
Wencheng
Hi
The error code you are looking for is STATUS_NOT_SAME_DEVICE. This
forces a copy and delete operation instead of a rename, I have been
using this for some time now and it seems to work really well.
Ben Curley
Software Engineer
Data Encryption Systems Ltd.
Tel: +44 (0)1823 352357 (Main)
Tel: +44 (0)1823 358320 (Direct Dial)
Web: http://www.deslock.com
-----Original Message-----
From: xxxxx@covad.net [mailto:xxxxx@covad.net]
Sent: 11 July 2003 23:09
To: File Systems Developers
Cc: xxxxx@yoshimuni.com
Subject: [ntfsd] Re: Rename a file and directory
Hi David,
Many thanks for your inputs, I will try EFS and see what
happen.
Wencheng
> Revisit your design. Far too complex. Just return the status that
> indicates a move is not possible. Try it with EFS and see what
> happens when a file is renamed from an encrypted directory to a
> plaintext directory and duplicate it. I think it will probably be an
> error that forces a program to use a copy and delete.
>
> What happens if one of the directories is joined or subst’d. A rename
> won’t work either.
>
> wrote in message news:xxxxx@ntfsd…
>>>
>>>
>>>
>>> Hi,
>>>
>>> The following are sequence of file operations that
>>> I would like to process them in my encryption filter driver.
>>>
>>> All the files in directory c:/a/b/c need to be encrypted and all the
>>> files in c:/x/y/z need to decrypted.
>>>
>>> create c:/a/b/c/source.txt
>>> write c:/a/b/c/source.txt
>>> close c:/a/b/c/source.txt
>>> create c:/x/y/z/target.txt
>>> rename c:/a/b/c/source.txt c:/x/y/z/target.txt
>>> delete c:/a/b/c/source.txt
>>>
>>> I read the rename operations in OSR’s “Filter Driver
>>> Discussion paper”, which is a very helpful information
>>> regarding “rename” operation. In the above rename
>>> case, it seems to me that my filter driver needs to
>>> create my own IRP to perform a “read” on source.txt
>>> and decrypt the data before creating another IRP to
>>> write target.txt in a decrypted directory. Is this
>>> approach sounds a right one in the filter driver?
>>> If I want to handle “rename c:/a/b/c c:/x/y/x” in my
>>> encryption filter driver, is it doable? Your input is
>>> really appreciated.
>>>
>>> Wencheng
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> You are currently subscribed to ntfsd as: xxxxx@covad.net To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@des.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@covad.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com