EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Questions about behaviour of delete and rename

Posted: 07/15/2010 06:26:00
by Thomas Mäder (Standard support level)
Joined: 05/26/2010
Posts: 11

After reading a bunch of posts about deleting files, I am still uncertain about a couple of points. So here's my understanding of how stuff works:

1) Someone opens a file with SHARE_DELETE
2) another program deletes the file. It is marked as deleted (internally in the CbFS driver)
3) a third program trying to open the file now gets a file_not_found error the file is not found when listing the parent directory

Question: what happens when a fourth program tries to create a file with the same name as the original? Would I get an onCreateFile event? Would there be an error?

4) The first program writes to it's handle. This works without a hitch.
5) The first and second file close their handles
6) I get an onDeleteFile event
Posted: 07/15/2010 07:29:39
by Thomas Mäder (Standard support level)
Joined: 05/26/2010
Posts: 11

It's bad form I guess to ask questions and then answer them yourself, but here goes: I've written a bogus little program like so:

   DWORD disposition= CREATE_ALWAYS;
   HANDLE h= CreateFile(L"c:\\temp\\foo.text", access, share, 0, disposition, 0, 0);

   printf("delete worked: %d\n", DeleteFile(L"c:\\temp\\foo.text"));

   HANDLE h2= CreateFile(L"c:\\temp\\foo.text", GENERIC_READ, share, 0, OPEN_EXISTING, 0, 0);
   printf("creating: %p, error= %d\n", h2, GetLastError());

   DWORD written= 0;

   WriteFile(h, "fooblaro", 5, &written, NULL);
   printf("write worked: %d\n", written);

Here's what win 7 with NTFS does:

1) DeleteFile() succeeds
2) when trying to open the second handle, I get ERROR_ACCESS_DENIED. The file is still visible in explorer at this time.
3) the WriteFile() and FlushFileBuffers() calls succeed. The file properties dialog now shows a file length of 5 bytes.
4) When I close the handle h, the file disappears from explorer

If I understand this right, the whole deleted file business can be handled inside windows or the CbFS driver. Can someone in the know confirm this?
Can someone confirm that this is indeed the intended (and documented) behaviour an all windows versions since XP SP3?
Posted: 07/15/2010 14:38:57
by Volodymyr Zinin (Team)

Windows does deletion in the following way -
1. A file is opened.
2. A special request (IRP_MJ_SET_INFORMATION with FileDispositionInformation) is sent to it. During this request the file is marked as "delete on close". Any subsequent opening or creating of a such marked file returns the STATUS_DELETE_PENDING error.
3. The file is closed and if it's still marked as "delete on close" then it's deleted.

BTW: Windows before placing a file in the recycle bin tries to mark the file as "delete on close" and immediately clear this flag (by the use of IRP_MJ_SET_INFORMATION with FileDispositionInformation). It does it in order to check whether the file can be deleted or not.

Thomas Mäder wrote:
Can someone confirm that this is indeed the intended (and documented) behaviour an all windows versions since XP SP3?

It isn't really a documented behavior (I mean the behavior during the following write and flush calls) but CallbackFS (and FATFS) works in such way too.



Topic viewed 1482 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!