A couple of Qs on rename & fastfat...

NTFSD
1
  1. I’ve noticed that fastfat doesn’t support “relative” rename (i.e. when
    PFILE_RENAME_INFORMATION -> RootDirectory != NULL). So, the questions is:
    is it OK for an FSD to do not support this type of rename and how this will
    affect apps (and, may be srv/redirs)?
  2. In “fully qualified” rename case I saw these lines of code:

…

//
// This name is by definition legal.
//

NewName = *((PUNICODE_STRING)&TargetFileObject->FileName);

…

where TargetFileObject is what is passed in
IrpSp->Parameters.SetFile.FileObject. Doesn’t this break the rule that
FileName should not be
“trusted” after create IRP is completed? Or it is an exception for “rename
target” create only?

TIA,

Vladimir

2

Since you are the implementor of the filesystem, you own
FileObject->FileName as soon as the IRP_MJ_CREATE hits your filesystem
device object, and you can put whatever you want there and keep it there
for however long you want, and nobody else can touch it :).

In practice, the weird thing in the fully-qualified case is that FastFat
expects IrpSp->Parameters.SetFile.FileObject to actually be a DIRECTORY
file object and yet it assumes
IrpSp->Parameters.SetFile.FileObject->FileName to be the filename for
the target of the rename! I had to rip apart NtSetInformationFile to see
what was going on - apparently IrpSp->Parameters.SetFile.FileObject must
be set to the result of an IoCreateFile call against the target path but
with the IO_OPEN_TARGET_DIRECTORY flag set. Now look at how FastFat
handles SL_OPEN_TARGET_DIRECTORY. It will open the directory part of
FileObject->FileName, then modify FileObject->FileName to throw away the
directory portion - as well as return a flag indicating whether that
FileName exists or not! Mind-numbing.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vladimir
Chtchetkine
Sent: Wednesday, January 22, 2003 3:02 PM
To: File Systems Developers
Subject: [ntfsd] A couple of Qs on rename & fastfat…

  1. I’ve noticed that fastfat doesn’t support “relative” rename (i.e.
    when PFILE_RENAME_INFORMATION -> RootDirectory != NULL). So, the
    questions is:
    is it OK for an FSD to do not support this type of rename and how this
    will affect apps (and, may be srv/redirs)?
  2. In “fully qualified” rename case I saw these lines of code:
    …
    //
    // This name is by definition legal.
    //
    NewName = *((PUNICODE_STRING)&TargetFileObject->FileName);
    …
    where TargetFileObject is what is passed in
    IrpSp->Parameters.SetFile.FileObject. Doesn’t this break the rule that
    FileName should not be
    “trusted” after create IRP is completed? Or it is an exception for
    “rename target” create only?
    TIA,
    Vladimir

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