Is this new file system behavior

NTFSD
1

Recently I started seeing some behavior which I did not notice till
recently. I can’t say for certain but it may be after SP4 install on Win2K
and some patch installations on XP.

Everytime a file deletion happens, I am getting 2 IRP_MJ_SET_INFORMATION
messages. One with DeleteFile flag set to true in
FILE_DISPOSITION_INFORMATION and second message with this flag not set. And
then third message comes for file rename. As far as I can recall, I don’t
remeber seeing 2 SET_INFORMATION messages in the past.

2

This is nothing new. It’s been seen in the past.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

3

What is the second SET_INFORMATION message? If its file deletion operation
why the send message does not have DeleteFile flag set. Could you please
explain?

Thanks

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Thursday, August 28, 2003 10:16 AM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

This is nothing new. It’s been seen in the past.

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

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

4

I believe that this is explorer making sure that the
file CAN be deleted before moving it to the recycle
bin.

The user can send as many SET_INFORMATION irps as they
want. The last one before IRP_MJ_CLEANUP (IIRC) wins.

In this case, Explorer sends the first delete, the FS
does all it’s checks to make sure the file can be
deleted and returns. Explorer then cancels the delete
and renames the file.

Randy

— “Kohli, Naveen” wrote:
> What is the second SET_INFORMATION message? If its
> file deletion operation
> why the send message does not have DeleteFile flag
> set. Could you please
> explain?
>
> Thanks
>
> -----Original Message-----
> From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
> Sent: Thursday, August 28, 2003 10:16 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: Is this new file system
> behavior
>
>
>
> This is nothing new. It’s been seen in the past.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file
> encryption services.
> Alfa File Protector - File protection and hiding
> library for Win32
> developers.
> Alfa File Monitor - File monitoring library for
> Win32 developers.
>
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@criticalsites.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

5

Yah. I’ve gotta believe it’s your Recycle Bin getting into the act.
Naveen, when you started seeing the 2 IRP_MJ_SET_INFORMATION requests, had
you recently changed your Recycle Bin settings or moved to a new machine
that might have different settings from your own?

Carl

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>
> I believe that this is explorer making sure that the
> file CAN be deleted before moving it to the recycle
> bin.
>
> The user can send as many SET_INFORMATION irps as they
> want. The last one before IRP_MJ_CLEANUP (IIRC) wins.
>
> In this case, Explorer sends the first delete, the FS
> does all it’s checks to make sure the file can be
> deleted and returns. Explorer then cancels the delete
> and renames the file.
>
> Randy
>

6

We did not change anything on any of the systems. All machines have fresh
installations of XP/Win2K. So what ever is the default setting. And this is
how our QA has been testing the product for years now. Here is what I have
observed.

  1. Explorer is triggering NtSetFileInformation call with DriverFile flag set
    to true. Fair enough.
  2. Then it is triggering second NtSetFileInformation but this time
    DriverFile flag is not set. But DeletePending flag is set in FILE_OBJECT.
  3. And then it does the rename of the file and triggers 3rd
    NtSetFileInformation call but this time for FileRename.

I am trying to figure out how did the 2nd call come into pircure.

Any insight will be greatly appreciated.

Thanks.

-----Original Message-----
From: Carl Appellof [mailto:xxxxx@nospam.veritas.com]
Sent: Thursday, August 28, 2003 5:31 PM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

Yah. I’ve gotta believe it’s your Recycle Bin getting into the act.
Naveen, when you started seeing the 2 IRP_MJ_SET_INFORMATION requests, had
you recently changed your Recycle Bin settings or moved to a new machine
that might have different settings from your own?

Carl

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>
> I believe that this is explorer making sure that the
> file CAN be deleted before moving it to the recycle
> bin.
>
> The user can send as many SET_INFORMATION irps as they
> want. The last one before IRP_MJ_CLEANUP (IIRC) wins.
>
> In this case, Explorer sends the first delete, the FS
> does all it’s checks to make sure the file can be
> deleted and returns. Explorer then cancels the delete
> and renames the file.
>
> Randy
>

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

7

I think we landed into same issue some time back. I will try to put down our
interpretation of this.

The Second call is to make sure the file does not actually gets deleted,
even after the “close” happens.

So, the first call is to make sure delete operation is ok on the file. If
its successful, the explorer then instead of sending IRP_MJ_CLOSE/CLEANUP,
which would actually delete the file, sends a file undelete notification as
it needs to send it to recycle bin.

I hope this helps.

Vikas

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Carl Appellof
Sent: Thursday, August 28, 2003 2:31 PM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

Yah. I’ve gotta believe it’s your Recycle Bin getting into the act.
Naveen, when you started seeing the 2 IRP_MJ_SET_INFORMATION requests, had
you recently changed your Recycle Bin settings or moved to a new machine
that might have different settings from your own?

Carl

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>
> I believe that this is explorer making sure that the
> file CAN be deleted before moving it to the recycle
> bin.
>
> The user can send as many SET_INFORMATION irps as they
> want. The last one before IRP_MJ_CLEANUP (IIRC) wins.
>
> In this case, Explorer sends the first delete, the FS
> does all it’s checks to make sure the file can be
> deleted and returns. Explorer then cancels the delete
> and renames the file.
>
> Randy
>

8

It’s recycle bin API.but I can’t sure it.
what about it?It’s very correct.
Deleted Flag is setted,then cancel it.and Rename.it’s correct.you can
handle it commonly.
until last Cleanup,the file with DELETED_ON_CLOSE flag will deleted.

Recently I started seeing some behavior which I did not notice till
recently. I can’t say for certain but it may be after SP4 install on Win2K
and some patch installations on XP.

Everytime a file deletion happens, I am getting 2 IRP_MJ_SET_INFORMATION
messages. One with DeleteFile flag set to true in
FILE_DISPOSITION_INFORMATION and second message with this flag not set. And
then third message comes for file rename. As far as I can recall, I don’t
remeber seeing 2 SET_INFORMATION messages in the past.

9

This is nothing new, its been the same for sure from W2K original. There
is at least one old thread here on this subject. I should know, I started
at least one :wink:

I also find that, when ‘deleting’ a tree to the recycle bin, the same
behaviour is observed for some files deep down the tree. I had a strong
suspicion these were always recently accessed/written files, which would
have been interesting.

10

The problem was that I had to deal with deletion notification before the
final cleanup. There is some processing that I have to do. I guess I will
have to deal with this differently now.

Thanks.

-----Original Message-----
From: ecore [mailto:xxxxx@hotmail.com]
Sent: Friday, August 29, 2003 7:05 AM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

It’s recycle bin API.but I can’t sure it.
what about it?It’s very correct.
Deleted Flag is setted,then cancel it.and Rename.it’s correct.you can
handle it commonly.
until last Cleanup,the file with DELETED_ON_CLOSE flag will deleted.

Recently I started seeing some behavior which I did not notice till
recently. I can’t say for certain but it may be after SP4 install on Win2K
and some patch installations on XP.

Everytime a file deletion happens, I am getting 2 IRP_MJ_SET_INFORMATION
messages. One with DeleteFile flag set to true in
FILE_DISPOSITION_INFORMATION and second message with this flag not set.
And
then third message comes for file rename. As far as I can recall, I don’t
remeber seeing 2 SET_INFORMATION messages in the past.

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

11

Thanks Vikas.
Thats pretty much the explanation I came up with. Now we are dealing with
this situation based on these conclusions.

-----Original Message-----
From: Vikas Ratna [mailto:xxxxx@agglut.com]
Sent: Thursday, August 28, 2003 7:26 PM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

I think we landed into same issue some time back. I will try to put down our
interpretation of this.

The Second call is to make sure the file does not actually gets deleted,
even after the “close” happens.

So, the first call is to make sure delete operation is ok on the file. If
its successful, the explorer then instead of sending IRP_MJ_CLOSE/CLEANUP,
which would actually delete the file, sends a file undelete notification as
it needs to send it to recycle bin.

I hope this helps.

Vikas

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Carl Appellof
Sent: Thursday, August 28, 2003 2:31 PM
To: File Systems Developers
Subject: [ntfsd] Re: Is this new file system behavior

Yah. I’ve gotta believe it’s your Recycle Bin getting into the act.
Naveen, when you started seeing the 2 IRP_MJ_SET_INFORMATION requests, had
you recently changed your Recycle Bin settings or moved to a new machine
that might have different settings from your own?

Carl

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>
> I believe that this is explorer making sure that the
> file CAN be deleted before moving it to the recycle
> bin.
>
> The user can send as many SET_INFORMATION irps as they
> want. The last one before IRP_MJ_CLEANUP (IIRC) wins.
>
> In this case, Explorer sends the first delete, the FS
> does all it’s checks to make sure the file can be
> deleted and returns. Explorer then cancels the delete
> and renames the file.
>
> Randy
>

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