Hi all,
I am changing the fileobjects in IRP_MJ_WRITE. So that the data to be
written in a file is directed to another. This works fine in case both
files are in the same File Systems (FAT32 to FAT32 OR NTFS to NTFS).
But it does give FAT_FILE_SYSTEM or NTFS_FILE_SYSTEM if one file system is
fat and the other is NTFS or vice versa.
Please help.
Thanks
Lalit
At least an illegal FCB is referenced. The FS has no internal representation
of that file.
Tobias
----- Original Message -----
From: “Lalit S. Rana”
To: “File Systems Developers”
Sent: Friday, June 20, 2003 12:40 PM
Subject: [ntfsd] Changing file objects yields errors
> Hi all,
> I am changing the fileobjects in IRP_MJ_WRITE. So that the data to be
> written in a file is directed to another. This works fine in case both
> files are in the same File Systems (FAT32 to FAT32 OR NTFS to NTFS).
>
> But it does give FAT_FILE_SYSTEM or NTFS_FILE_SYSTEM if one file system is
> fat and the other is NTFS or vice versa.
This means that the file system driver found a wrong file object in its
current stack location.
Do you redirect only non-cached IRP or every IRP?
You are concerned about data on disk, so no need to touch cached requests.
If you have source code for FAT you can check where FAT got the file object
from when crash occur.
I know that replacing FileObject works if only non-cached requests are being
redirected; I am not sure if it works if both cached and non-cached requests
are redirected, there may be some side effects I am not aware of.
Alexei.
“Lalit S. Rana” wrote in message news:xxxxx@ntfsd…
>
> Hi all,
> I am changing the fileobjects in IRP_MJ_WRITE. So that the data to be
> written in a file is directed to another. This works fine in case both
> files are in the same File Systems (FAT32 to FAT32 OR NTFS to NTFS).
>
> But it does give FAT_FILE_SYSTEM or NTFS_FILE_SYSTEM if one file system is
> fat and the other is NTFS or vice versa.
>
> Please help.
> Thanks
> Lalit
>
>
The Microsoft document doesn’t helps much for this error.
Could somebody please tell what this error signifies.
FAT_FILE_SYSTEM
0X00000023(0X0011012B,0X00000705,0X00000000,0x0000000)
Thanks and regards.
Lalit
This means that the internal FastFat function ‘FatDecodeFileObject’
bugchecked because you passed down a file object that the FastFat driver
doesn’t recognize. The documentation for this and other bugcheck codes
can be found in the help file installed with WinDbg. For this code
specifically, the first parameter tells you the source file and line
number where the bugcheck occurred in the FastFat source. From there on,
you can inspect the FastFat source in the IFSKIT to determine exactly
what the problem was.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lalit S. Rana
Sent: Friday, June 20, 2003 10:19 PM
To: File Systems Developers
Subject: [ntfsd] Re: Changing file objects yields errorsThe Microsoft document doesn’t helps much for this error.
Could somebody please tell what this error signifies.FAT_FILE_SYSTEM
0X00000023(0X0011012B,0X00000705,0X00000000,0x0000000)Thanks and regards.
Lalit
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You must be sure, that you forward your request to the FSD for which it was
created. This means that if original request comes for drive C: and you want
to redirect file operation to another drive (say D:), you must call
IoCallDriver with device object representing drive D:. Changing file objects
in IRP is not a good idea in this case because other device object may have
another parameters (StackSize for example or DO flags). I would roll my own
IRP to write to another file while holding (or pending) original request.
-htfv
----- Original Message -----
From: “Lalit S. Rana”
To: “File Systems Developers”
Sent: Friday, June 20, 2003 1:40 PM
Subject: [ntfsd] Changing file objects yields errors
> Hi all,
> I am changing the fileobjects in IRP_MJ_WRITE. So that the data to be
> written in a file is directed to another. This works fine in case both
> files are in the same File Systems (FAT32 to FAT32 OR NTFS to NTFS).
>
> But it does give FAT_FILE_SYSTEM or NTFS_FILE_SYSTEM if one file system is
> fat and the other is NTFS or vice versa.
>
> Please help.
> Thanks
> Lalit
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Sorry, in the first sentence I meant you must forward request to the FSD
device object for which *file object* was created.
-htfv
----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Sunday, June 22, 2003 2:12 PM
Subject: [ntfsd] Re: Changing file objects yields errors
> You must be sure, that you forward your request to the FSD for which it
was
> created. This means that if original request comes for drive C: and you
want
> to redirect file operation to another drive (say D:), you must call
> IoCallDriver with device object representing drive D:. Changing file
objects
> in IRP is not a good idea in this case because other device object may
have
> another parameters (StackSize for example or DO flags). I would roll my
own
> IRP to write to another file while holding (or pending) original request.
>
> -htfv
>
>
> ----- Original Message -----
> From: “Lalit S. Rana”
> To: “File Systems Developers”
> Sent: Friday, June 20, 2003 1:40 PM
> Subject: [ntfsd] Changing file objects yields errors
>
>
> > Hi all,
> > I am changing the fileobjects in IRP_MJ_WRITE. So that the data to be
> > written in a file is directed to another. This works fine in case both
> > files are in the same File Systems (FAT32 to FAT32 OR NTFS to NTFS).
> >
> > But it does give FAT_FILE_SYSTEM or NTFS_FILE_SYSTEM if one file system
is
> > fat and the other is NTFS or vice versa.
> >
> > Please help.
> > Thanks
> > Lalit
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>