Need to develop a filter driver or full IFS (or something else)?

NTFSD
1

Hello all,

If I may, I’d like to tap the file system Jedis on this list for a
little advice, and I’ll try to simplify my question as much as possible.
In essence, my requirement is a fully-functional “virtual drive” that
can be traversed in Windows Explorer, referenced from the console, for
which all reads and writes are intercepted. This virtual drive doesn’t
need the functionality of a new type of file system per se, as it is
essentially using a standard NTFS drive for reads and writes under the
hood, but when a read or write is done, I need to intercept those calls,
and read or write the file in a custom fashion.

I developed a shell namespace extension, which although not completely
graceful throughout, basically does the entire job, except for two
primary things: writes into the namespace are not intercepted or
detected, and it cannot be referenced from the console (to my
knowledge). I have been researching installable filesystems, filter
drivers, and FUSE. I don’t appear to need a whole new file system as I
understand it; I don’t really need new filesystem functionality per se
– I am fine to (eventually) write to an alternate file / directory
structure of my own on the C: or D: drives (NTFS); I just need to alter
what files are read / written. FUSE is not presently ported to Windows.
I’ve followed the thread on FUSE, and it appears that porting FUSE would
be a fairly sizable task.

After researching the matter, it seems that the proper route would be a
filter driver, although I’m not quite sure how I get this filter driver
“paired” if you will with a mounted drive that is accessible both from
Explorer, and from the console.

What do you recommend?

Thanks – your help is greatly appreciated.

Brad

2

Brad,

Write a driver that presents a mount point or even virtual partition.
There are some example source online. A few years ago I wrote one
for presenting data from another source and it wasn’t a big project
at all.

I’m not sure how you get there as a file system or file system filter
driver.

Hope this helps.

Rick…

=========================

Hello all,

If I may, I’d like to tap the file system Jedis on this list for a
little advice, and I’ll try to simplify my question as much as possible.
In essence, my requirement is a fully-functional “virtual drive” that
can be traversed in Windows Explorer, referenced from the console, for
which all reads and writes are intercepted. This virtual drive doesn’t
need the functionality of a new type of file system per se, as it is
essentially using a standard NTFS drive for reads and writes under the
hood, but when a read or write is done, I need to intercept those calls,
and read or write the file in a custom fashion.

I developed a shell namespace extension, which although not completely
graceful throughout, basically does the entire job, except for two
primary things: writes into the namespace are not intercepted or
detected, and it cannot be referenced from the console (to my
knowledge). I have been researching installable filesystems, filter
drivers, and FUSE. I don’t appear to need a whole new file system as I
understand it; I don’t really need new filesystem functionality per se
– I am fine to (eventually) write to an alternate file / directory
structure of my own on the C: or D: drives (NTFS); I just need to alter
what files are read / written. FUSE is not presently ported to Windows.
I’ve followed the thread on FUSE, and it appears that porting FUSE would
be a fairly sizable task.

After researching the matter, it seems that the proper route would be a
filter driver, although I’m not quite sure how I get this filter driver
“paired” if you will with a mounted drive that is accessible both from
Explorer, and from the console.

What do you recommend?

Thanks – your help is greatly appreciated.

Brad

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

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

3

You don’t indicate if you need to act on individual files or on the drive
as a whole. This one question will significantly impact the amount of work
you need to do. If you don’t need to know the individual file, just the
drive space, you can do this with a virtual disk. The ramdisk sample from
Microsoft is a good starting point. Be careful not to use the FileDisk
sample as that is stolen code.

Now if you need to deal with individual files, do you want a copy
underneath on an existing file system? I.E. You have an NTFS volume, but
you are doing special actions on read/write’s and probably only on data
files? If this is the scenario, then use a file system filter. Use the
mini-filter model as a starting point.

From you description you probably need a file system filter.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Brad O’Hearne” wrote in message news:xxxxx@ntfsd…
> Hello all,
>
> If I may, I’d like to tap the file system Jedis on this list for a little
> advice, and I’ll try to simplify my question as much as possible. In
> essence, my requirement is a fully-functional “virtual drive” that can be
> traversed in Windows Explorer, referenced from the console, for which all
> reads and writes are intercepted. This virtual drive doesn’t need the
> functionality of a new type of file system per se, as it is essentially
> using a standard NTFS drive for reads and writes under the hood, but when
> a read or write is done, I need to intercept those calls, and read or
> write the file in a custom fashion.
>
> I developed a shell namespace extension, which although not completely
> graceful throughout, basically does the entire job, except for two
> primary things: writes into the namespace are not intercepted or
> detected, and it cannot be referenced from the console (to my knowledge).
> I have been researching installable filesystems, filter drivers, and
> FUSE. I don’t appear to need a whole new file system as I understand it;
> I don’t really need new filesystem functionality per se – I am fine to
> (eventually) write to an alternate file / directory structure of my own
> on the C: or D: drives (NTFS); I just need to alter what files are read /
> written. FUSE is not presently ported to Windows. I’ve followed the
> thread on FUSE, and it appears that porting FUSE would be a fairly
> sizable task.
>
> After researching the matter, it seems that the proper route would be a
> filter driver, although I’m not quite sure how I get this filter driver
> “paired” if you will with a mounted drive that is accessible both from
> Explorer, and from the console.
>
> What do you recommend?
>
> Thanks – your help is greatly appreciated.
>
> Brad
>
>

4

Don,

Thanks for the reply. I basically will need to act on all individual
files that exist (are being read from or written to) the virtual drive.
I believe this will require at a minimum the following:

  • a mounted drive, which can be accessed from the console or windows
    explorer (obviously, the user needs a way to access the virtual drive)
  • the filter (I presume) must know what file is being operated on (and
    what drive it resides on, if the filter will also be passed files from
    other existing drives, such as C: – I’m not exactly sure about that
    yet, but perhaps you can shed light on it).
  • the filter will actually be reading and writing files to an existing
    NTFS drive (like C:) under the hood, unbeknownst to the user who
    executed the operation.

It sounds as if your thoughts are similar to what I’ve concluded from
the research I have done. I thought the file system filter was what I
needed, but I’m not entirely clear on the way to expose this
functionality via a mounted drive. The secure namespace extension works
great for explorer, but isn’t a mounted drive per se, and can’t be
refrerenced from the console or scripts. If I have this filter in place,
what is the best way to expose this mounted drive, and intercept all
read / write requests from it via the filter?

Thanks,

Brad

Don Burn wrote:

You don’t indicate if you need to act on individual files or on the drive
as a whole. This one question will significantly impact the amount of work
you need to do. If you don’t need to know the individual file, just the
drive space, you can do this with a virtual disk. The ramdisk sample from
Microsoft is a good starting point. Be careful not to use the FileDisk
sample as that is stolen code.

Now if you need to deal with individual files, do you want a copy
underneath on an existing file system? I.E. You have an NTFS volume, but
you are doing special actions on read/write’s and probably only on data
files? If this is the scenario, then use a file system filter. Use the
mini-filter model as a starting point.

From you description you probably need a file system filter.

5

Brad,

Is this a true virtual drive, in the sense of there is not NTFS or
FAT, etc beneath it? If is is the drive will be there by default, since
the OS will still see the mount of the underlying file system, it is just
that your filter will sit in between the OS and the file system code to
modify the requests you need to.

Now, a couple of questions to help you know whether you want to go
there. Do you actions for read and write modify the size of the file? If
so this is a lot more work. What happens if your actions are not done?
I.E. what are the consequences, for instance if this encrypts/decrypts then
things are not accessible, but there is no inconsistency on the drive.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Brad O’Hearne” wrote in message news:xxxxx@ntfsd…
> Don,
>
> Thanks for the reply. I basically will need to act on all individual
> files that exist (are being read from or written to) the virtual drive. I
> believe this will require at a minimum the following:
>
> - a mounted drive, which can be accessed from the console or windows
> explorer (obviously, the user needs a way to access the virtual drive)
> - the filter (I presume) must know what file is being operated on (and
> what drive it resides on, if the filter will also be passed files from
> other existing drives, such as C: – I’m not exactly sure about that yet,
> but perhaps you can shed light on it).
> - the filter will actually be reading and writing files to an existing
> NTFS drive (like C:) under the hood, unbeknownst to the user who executed
> the operation.
>
> It sounds as if your thoughts are similar to what I’ve concluded from the
> research I have done. I thought the file system filter was what I needed,
> but I’m not entirely clear on the way to expose this functionality via a
> mounted drive. The secure namespace extension works great for explorer,
> but isn’t a mounted drive per se, and can’t be refrerenced from the
> console or scripts. If I have this filter in place, what is the best way
> to expose this mounted drive, and intercept all read / write requests
> from it via the filter?
>
> Thanks,
>
> Brad
>
> Don Burn wrote:
>> You don’t indicate if you need to act on individual files or on the
>> drive as a whole. This one question will significantly impact the amount
>> of work you need to do. If you don’t need to know the individual file,
>> just the drive space, you can do this with a virtual disk. The ramdisk
>> sample from Microsoft is a good starting point. Be careful not to use
>> the FileDisk sample as that is stolen code.
>>
>> Now if you need to deal with individual files, do you want a copy
>> underneath on an existing file system? I.E. You have an NTFS volume,
>> but you are doing special actions on read/write’s and probably only on
>> data files? If this is the scenario, then use a file system filter.
>> Use the mini-filter model as a starting point.
>>
>> From you description you probably need a file system filter.
>>
>>
>>
>
>

6

Don,

I’ll do my best to explain the nature of this “virtual drive”, or
whatever the proper term is.

USER VIEW
Here’s the view from the users’ standpoint. Users needs to have some
mounted drive to address, we’ll call it the “BradDrive”. BradDrive needs
to be accessible in Windows Explorer, from the console, from scripts
etc. BradDrive needs to look from the user’s perspective like a unique
drive of its own, which contains a standard file / folder hierarchy.

UNDER THE HOOD
Under the hood, i.e. what is really taking place in the BradDrive
implementation, is that when a request is being made for folders,
children of folders, and files, I’m actually reading a hierarchy of
folders and stub files stored in a work area (special directory my app
is aware of) on the C: drive, and returning the actual file/folder and
file info/folder info, which I obtain unbeknownst to the user from
elsewhere.As mentioned before, a shell namespace extension nearly does
the job – it just doesn’t have any hooks to writes to this drive, and
it also isn’t referencable (to my knowledge) from the console or scripts.

In answer to your two questions:

  • Do you actions for read and write modify the size of the file?

A: Not as far as the user is concerned. It will look exactly the same to
the user, as far as file size reported. Under the hood, it may well be
changed. Your encryption analogy is a good one – assume that scenario,
but assume that I’m reporting the original file size back to the user,
not the file size after encryption.

  • What happens if your actions are not done?
    I.E. what are the consequences, for instance if this encrypts/decrypts then
    things are not accessible, but there is no inconsistency on the drive.

A: If the action isn’t done, or fails, then the entire attempted action
fails. In other words, if a read attempt by the user results in a failed
read attempt by my filter, the entire read attempt fails.If a write
attempt by the user results in a failed write attempt by my filter, the
entire write attempt fails.

It sounds like I need a system filter driver. But it also sounds like I
need some way to mount this drive.

Thanks for all your help Don – it is greatly appreciated. I look
forward to your response.

Brad

Don Burn wrote:

Brad,

Is this a true virtual drive, in the sense of there is not NTFS or
FAT, etc beneath it? If is is the drive will be there by default, since
the OS will still see the mount of the underlying file system, it is just
that your filter will sit in between the OS and the file system code to
modify the requests you need to.

Now, a couple of questions to help you know whether you want to go
there. Do you actions for read and write modify the size of the file? If
so this is a lot more work. What happens if your actions are not done?
I.E. what are the consequences, for instance if this encrypts/decrypts then
things are not accessible, but there is no inconsistency on the drive.

7

You neglected to provide the information about the format of the drive. Is
it in FAT32 or NTFS or CDFS format? Can it be done so even if it is not
really in one of those formats? Can it be a network file system using RDR?
If no to all the above, you need a file system driver and recognizer. OSR
sells a kit to help you with that.

“Brad O’Hearne” wrote in message news:xxxxx@ntfsd…
> Don,
>
> I’ll do my best to explain the nature of this “virtual drive”, or whatever
> the proper term is.
>
> USER VIEW
> Here’s the view from the users’ standpoint. Users needs to have some
> mounted drive to address, we’ll call it the “BradDrive”. BradDrive needs
> to be accessible in Windows Explorer, from the console, from scripts etc.
> BradDrive needs to look from the user’s perspective like a unique drive of
> its own, which contains a standard file / folder hierarchy.
>
> UNDER THE HOOD
> Under the hood, i.e. what is really taking place in the BradDrive
> implementation, is that when a request is being made for folders, children
> of folders, and files, I’m actually reading a hierarchy of folders and
> stub files stored in a work area (special directory my app is aware of) on
> the C: drive, and returning the actual file/folder and file info/folder
> info, which I obtain unbeknownst to the user from elsewhere.As mentioned
> before, a shell namespace extension nearly does the job – it just
> doesn’t have any hooks to writes to this drive, and it also isn’t
> referencable (to my knowledge) from the console or scripts.
>
> In answer to your two questions:
>
> - Do you actions for read and write modify the size of the file?
>
> A: Not as far as the user is concerned. It will look exactly the same to
> the user, as far as file size reported. Under the hood, it may well be
> changed. Your encryption analogy is a good one – assume that scenario,
> but assume that I’m reporting the original file size back to the user, not
> the file size after encryption.
>
> - What happens if your actions are not done? I.E. what are the
> consequences, for instance if this encrypts/decrypts then things are not
> accessible, but there is no inconsistency on the drive.
>
> A: If the action isn’t done, or fails, then the entire attempted action
> fails. In other words, if a read attempt by the user results in a failed
> read attempt by my filter, the entire read attempt fails.If a write
> attempt by the user results in a failed write attempt by my filter, the
> entire write attempt fails.
>
> It sounds like I need a system filter driver. But it also sounds like I
> need some way to mount this drive.
>
> Thanks for all your help Don – it is greatly appreciated. I look forward
> to your response.
>
> Brad
>
>
> Don Burn wrote:
>> Brad,
>>
>> Is this a true virtual drive, in the sense of there is not NTFS or
>> FAT, etc beneath it? If is is the drive will be there by default, since
>> the OS will still see the mount of the underlying file system, it is just
>> that your filter will sit in between the OS and the file system code to
>> modify the requests you need to.
>>
>> Now, a couple of questions to help you know whether you want to go
>> there. Do you actions for read and write modify the size of the file?
>> If so this is a lot more work. What happens if your actions are not
>> done? I.E. what are the consequences, for instance if this
>> encrypts/decrypts then things are not accessible, but there is no
>> inconsistency on the drive.
>>
>>
>>
>
>

8

David,

Thank you for the reply. Forgive me for possibly doing a bad job
describing things clearly. I’ll try to do a little better here. Answers
to your questions:

  • You neglected to provide the information about the format of the drive. Is
    it in FAT32 or NTFS or CDFS format?

A: If you are referring to the virtual drive, when you say “the drive”
(versus the one underneath it), then the answer is – it doesn’t really
matter per se. This drive is truly virtual. It isn’t a real “drive”, it
is merely a logical structure, which is maintained by files located on
an existing hard drive (C: or D: for example). Whether the underlying
disk is FAT32 or NTFS I do not care. The virtual drive will write to it
and read from it, regardless of format, just as long as the system can
read and write from it by default (meaning its present configuration –
i.e. if I am using the D: drive to read/write in my virtual drive
implementation, then just as long as a read/write can be done to this
mounted drive, then I’m fine.)

  • Can it be done so even if it is not really in one of those formats?

A: The underlying drive this virtual drive will actually read to/write
from is essentially going to be an existing hard drive. FAT32, NTFS, I
don’t care. Either one will work.

Can it be a network file system using RDR?

A: Not really. Just assume its leveraging an existing local filesystem
(hard drive).

Am I still in the neighborhood of the OSR drive option?

Thanks,

Brad

David J. Craig wrote:

You neglected to provide the information about the format of the drive. Is
it in FAT32 or NTFS or CDFS format? Can it be done so even if it is not
really in one of those formats? Can it be a network file system using RDR?
If no to all the above, you need a file system driver and recognizer. OSR
sells a kit to help you with that.

“Brad O’Hearne” wrote in message news:xxxxx@ntfsd…
>
>> Don,
>>
>> I’ll do my best to explain the nature of this “virtual drive”, or whatever
>> the proper term is.
>>
>> USER VIEW
>> Here’s the view from the users’ standpoint. Users needs to have some
>> mounted drive to address, we’ll call it the “BradDrive”. BradDrive needs
>> to be accessible in Windows Explorer, from the console, from scripts etc.
>> BradDrive needs to look from the user’s perspective like a unique drive of
>> its own, which contains a standard file / folder hierarchy.
>>
>> UNDER THE HOOD
>> Under the hood, i.e. what is really taking place in the BradDrive
>> implementation, is that when a request is being made for folders, children
>> of folders, and files, I’m actually reading a hierarchy of folders and
>> stub files stored in a work area (special directory my app is aware of) on
>> the C: drive, and returning the actual file/folder and file info/folder
>> info, which I obtain unbeknownst to the user from elsewhere.As mentioned
>> before, a shell namespace extension nearly does the job – it just
>> doesn’t have any hooks to writes to this drive, and it also isn’t
>> referencable (to my knowledge) from the console or scripts.
>>
>> In answer to your two questions:
>>
>> - Do you actions for read and write modify the size of the file?
>>
>> A: Not as far as the user is concerned. It will look exactly the same to
>> the user, as far as file size reported. Under the hood, it may well be
>> changed. Your encryption analogy is a good one – assume that scenario,
>> but assume that I’m reporting the original file size back to the user, not
>> the file size after encryption.
>>
>> - What happens if your actions are not done? I.E. what are the
>> consequences, for instance if this encrypts/decrypts then things are not
>> accessible, but there is no inconsistency on the drive.
>>
>> A: If the action isn’t done, or fails, then the entire attempted action
>> fails. In other words, if a read attempt by the user results in a failed
>> read attempt by my filter, the entire read attempt fails.If a write
>> attempt by the user results in a failed write attempt by my filter, the
>> entire write attempt fails.
>>
>> It sounds like I need a system filter driver. But it also sounds like I
>> need some way to mount this drive.
>>
>> Thanks for all your help Don – it is greatly appreciated. I look forward
>> to your response.
>>
>> Brad
>>
>>
>> Don Burn wrote:
>>
>>> Brad,
>>>
>>> Is this a true virtual drive, in the sense of there is not NTFS or
>>> FAT, etc beneath it? If is is the drive will be there by default, since
>>> the OS will still see the mount of the underlying file system, it is just
>>> that your filter will sit in between the OS and the file system code to
>>> modify the requests you need to.
>>>
>>> Now, a couple of questions to help you know whether you want to go
>>> there. Do you actions for read and write modify the size of the file?
>>> If so this is a lot more work. What happens if your actions are not
>>> done? I.E. what are the consequences, for instance if this
>>> encrypts/decrypts then things are not accessible, but there is no
>>> inconsistency on the drive.
>>>
>>>
>>>
>>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@neurofire.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

9

I wouldn’t try to do a drive simulation unless you just love do it. It
would be easier to write, but you would have to create all the FAT32
structures in memory and keep them updated, while doing IO to the real
files. I think this best works as a network redirector. I have never done
one of those, but you can find two samples in the WDK - nulmrx and smbmrx.
I also think there are some available for purchase.

“Brad O’Hearne” wrote in message news:xxxxx@ntfsd…
> David,
>
> Thank you for the reply. Forgive me for possibly doing a bad job
> describing things clearly. I’ll try to do a little better here. Answers to
> your questions:
>
> - You neglected to provide the information about the format of the drive.
> Is it in FAT32 or NTFS or CDFS format?
> A: If you are referring to the virtual drive, when you say “the drive”
> (versus the one underneath it), then the answer is – it doesn’t really
> matter per se. This drive is truly virtual. It isn’t a real “drive”, it is
> merely a logical structure, which is maintained by files located on an
> existing hard drive (C: or D: for example). Whether the underlying disk is
> FAT32 or NTFS I do not care. The virtual drive will write to it and read
> from it, regardless of format, just as long as the system can read and
> write from it by default (meaning its present configuration –
> i.e. if I am using the D: drive to read/write in my virtual drive
> implementation, then just as long as a read/write can be done to this
> mounted drive, then I’m fine.)
>
> - Can it be done so even if it is not really in one of those formats?
> A: The underlying drive this virtual drive will actually read to/write
> from is essentially going to be an existing hard drive. FAT32, NTFS, I
> don’t care. Either one will work.
>
> Can it be a network file system using RDR?
> A: Not really. Just assume its leveraging an existing local filesystem
> (hard drive).
>
> Am I still in the neighborhood of the OSR drive option?
>
> Thanks,
>
> Brad
>
> David J. Craig wrote:
>> You neglected to provide the information about the format of the drive.
>> Is it in FAT32 or NTFS or CDFS format? Can it be done so even if it is
>> not really in one of those formats? Can it be a network file system
>> using RDR? If no to all the above, you need a file system driver and
>> recognizer. OSR sells a kit to help you with that.
>>
>> “Brad O’Hearne” wrote in message
>> news:xxxxx@ntfsd…
>>
>>> Don,
>>>
>>> I’ll do my best to explain the nature of this “virtual drive”, or
>>> whatever the proper term is.
>>>
>>> USER VIEW
>>> Here’s the view from the users’ standpoint. Users needs to have some
>>> mounted drive to address, we’ll call it the “BradDrive”. BradDrive needs
>>> to be accessible in Windows Explorer, from the console, from scripts
>>> etc. BradDrive needs to look from the user’s perspective like a unique
>>> drive of its own, which contains a standard file / folder hierarchy.
>>>
>>> UNDER THE HOOD
>>> Under the hood, i.e. what is really taking place in the BradDrive
>>> implementation, is that when a request is being made for folders,
>>> children of folders, and files, I’m actually reading a hierarchy of
>>> folders and stub files stored in a work area (special directory my app
>>> is aware of) on the C: drive, and returning the actual file/folder and
>>> file info/folder info, which I obtain unbeknownst to the user from
>>> elsewhere.As mentioned before, a shell namespace extension nearly does
>>> the job – it just doesn’t have any hooks to writes to this drive, and
>>> it also isn’t referencable (to my knowledge) from the console or
>>> scripts.
>>>
>>> In answer to your two questions:
>>>
>>> - Do you actions for read and write modify the size of the file?
>>>
>>> A: Not as far as the user is concerned. It will look exactly the same to
>>> the user, as far as file size reported. Under the hood, it may well be
>>> changed. Your encryption analogy is a good one – assume that scenario,
>>> but assume that I’m reporting the original file size back to the user,
>>> not the file size after encryption.
>>>
>>> - What happens if your actions are not done? I.E. what are the
>>> consequences, for instance if this encrypts/decrypts then things are not
>>> accessible, but there is no inconsistency on the drive.
>>>
>>> A: If the action isn’t done, or fails, then the entire attempted action
>>> fails. In other words, if a read attempt by the user results in a failed
>>> read attempt by my filter, the entire read attempt fails.If a write
>>> attempt by the user results in a failed write attempt by my filter, the
>>> entire write attempt fails.
>>>
>>> It sounds like I need a system filter driver. But it also sounds like I
>>> need some way to mount this drive.
>>>
>>> Thanks for all your help Don – it is greatly appreciated. I look
>>> forward to your response.
>>>
>>> Brad
>>>
>>>
>>> Don Burn wrote:
>>>
>>>> Brad,
>>>>
>>>> Is this a true virtual drive, in the sense of there is not NTFS
>>>> or FAT, etc beneath it? If is is the drive will be there by default,
>>>> since the OS will still see the mount of the underlying file system, it
>>>> is just that your filter will sit in between the OS and the file system
>>>> code to modify the requests you need to.
>>>>
>>>> Now, a couple of questions to help you know whether you want to go
>>>> there. Do you actions for read and write modify the size of the file?
>>>> If so this is a lot more work. What happens if your actions are not
>>>> done? I.E. what are the consequences, for instance if this
>>>> encrypts/decrypts then things are not accessible, but there is no
>>>> inconsistency on the drive.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@neurofire.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>