2013-03-16 20:48:10 +00:00
|
|
|
/*
|
1999-04-14 00:52:19 +00:00
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
* PROJECT: ReactOS system libraries
|
2015-11-14 14:57:11 +00:00
|
|
|
* FILE: dll/win32/kernel32/client/file/delete.c
|
1999-05-19 18:00:17 +00:00
|
|
|
* PURPOSE: Deleting files
|
2000-03-14 23:09:23 +00:00
|
|
|
* PROGRAMMER: Ariadne (ariadne@xs4all.nl)
|
1999-04-14 00:52:19 +00:00
|
|
|
* UPDATE HISTORY:
|
|
|
|
* Created 01/11/98
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES ****************************************************************/
|
|
|
|
|
2003-01-15 21:24:36 +00:00
|
|
|
#include <k32.h>
|
[KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to).
As an additional feature on top of the "allow non-existing functions to be exported" "feature", because rbuild generates and links STDCALL function names without the proper decoration (vs. enforcing decoration at linking, but only removing it at export-time), this allows the definition (as an export) of a STDCALL function that is completely different from the actual function itself.
For example, the 5-parameter Foo function is normally Foo@20, while the 3-parameter Foo function woudl be Foo@12. Linking one against the other would fail (say, 2 parameters were added to Foo in a newer version). However, under RBUILD, both of these would appear as "Foo", and the linker/compiler would happilly connect the caller of Foo@3 (that has pushed 3 parameters) to the receiving side of Foo@5 (that is about to pop 5 parameters).
Even -if- decorations WERE to be applied, Foo@12 would STILL succeed, because of the first feature, which would enable the export of Foo@12 even though no such function exist.
In a further, bizare, twist of fate, the behavior of this RBUILD "feature", when the target function is not found, is to link the exported DLL TO ITSELF.
Therefore, one can see how, previously to this patch, kernel32.dll would import a dozen functions from itself (all the non-existing functions).
To really seal the deal, the behavior of exported functions used by kernel32, but that are actually forwarded to another DLL deserves a special mention.
GetLastError, for example, merely forwards to RtlGetLastWin32Error, so it is normal behavior to use a #define in the C code so that all internal calls to the function are routed correctly.
This did not happen, so instead, kernel32 tried importing/linking/exporting GetLastError, but this symbol is not found in the binary, because it is only a forwarder.
This caused kernel32 to import from itself (the behavior when an exported symbol is not found). When importing from itself, the loader would now find the _forwarded_ for GetLastError, and correctly link with ntdll.
What should be a one-liner of assembly (inline TEB access) thus became a triple-call indirection (GetLastError@0->StubLastError@0->__impGetLastError@0->__impRtlGetLastWin32Error->RtlGetLastWin32Error.
While analyzing these issues, we also realized a strange macro SetLastErrorByStatus that manually tried to perform what there already exists a function for: RtlSetLastNtStatusFromWin32Error.
And, in an exciting coda, we also realized that our Server 2003 Kernel32 exports more than a dozen Windows 95 APIs, through an auto-stub generation mechanism within winebuild, that gets linked as an object behind the scenes.
[KERNEL32]: Removed all Win95 exports, cleaned up exports.
[KERNEL32]: Fixed up set/get error macros by making them inline and/or calling the correct ntdll function.
[KERNEL32]: Removed bizare calls to Wine-internal/specific APIs from our core Win32 DLL.
[KERNEL32]: Wrote stubs for all functions which should be exported, and set the correct number of parameters for them.
[KERNEL32]: Kernel32 is smaller, loads faster, does not export Windows 95 functions, does not export non-existing functions, and does not import from itself anymore.
Note: This is one of the many failings of RBUILD the CMAKE system has helped us discover. I believe these issues are serious enough to warrant an immediate sync with trunk, but rest assured, there are many more completely broken, infinitely-regressing things that we discovered while switching to CMAKE.
svn path=/trunk/; revision=48475
2010-08-07 05:02:58 +00:00
|
|
|
#define NDEBUG
|
|
|
|
#include <reactos/debug.h>
|
1999-06-27 23:08:31 +00:00
|
|
|
|
1999-04-14 00:52:19 +00:00
|
|
|
/* FUNCTIONS ****************************************************************/
|
|
|
|
|
2003-07-10 18:50:51 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
2004-01-23 16:37:11 +00:00
|
|
|
BOOL
|
2008-11-30 11:42:05 +00:00
|
|
|
WINAPI
|
2012-05-23 16:51:22 +00:00
|
|
|
DeleteFileA(IN LPCSTR lpFileName)
|
1999-04-14 00:52:19 +00:00
|
|
|
{
|
2012-05-23 16:51:22 +00:00
|
|
|
PUNICODE_STRING FileName;
|
2005-05-09 01:46:57 +00:00
|
|
|
|
2012-05-23 16:51:22 +00:00
|
|
|
/* Convert the string to unicode, and call the wide function */
|
|
|
|
FileName = Basep8BitStringToStaticUnicodeString(lpFileName);
|
|
|
|
if (FileName) return DeleteFileW(FileName->Buffer);
|
|
|
|
return FALSE;
|
1999-04-14 00:52:19 +00:00
|
|
|
}
|
|
|
|
|
2003-07-10 18:50:51 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
2004-01-23 16:37:11 +00:00
|
|
|
BOOL
|
2008-11-30 11:42:05 +00:00
|
|
|
WINAPI
|
2012-05-23 16:51:22 +00:00
|
|
|
DeleteFileW(IN LPCWSTR lpFileName)
|
1999-04-14 00:52:19 +00:00
|
|
|
{
|
2012-05-23 16:51:22 +00:00
|
|
|
FILE_DISPOSITION_INFORMATION FileDispInfo;
|
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
IO_STATUS_BLOCK IoStatusBlock;
|
|
|
|
UNICODE_STRING NtPathU;
|
|
|
|
HANDLE FileHandle;
|
|
|
|
NTSTATUS Status;
|
|
|
|
RTL_RELATIVE_NAME_U RelativeName;
|
|
|
|
PWCHAR PathBuffer;
|
|
|
|
FILE_ATTRIBUTE_TAG_INFORMATION FileTagInformation;
|
|
|
|
|
|
|
|
/* Convert to NT path and get the relative name too */
|
|
|
|
if (!RtlDosPathNameToNtPathName_U(lpFileName,
|
|
|
|
&NtPathU,
|
|
|
|
NULL,
|
|
|
|
&RelativeName))
|
|
|
|
{
|
|
|
|
/* Bail out if the path name makes no sense */
|
|
|
|
SetLastError(ERROR_PATH_NOT_FOUND);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Save the path buffer in case we free it later */
|
|
|
|
PathBuffer = NtPathU.Buffer;
|
|
|
|
|
|
|
|
/* If we have a relative name... */
|
|
|
|
if (RelativeName.RelativeName.Length)
|
|
|
|
{
|
|
|
|
/* Do a relative open with only the relative path set */
|
|
|
|
NtPathU = RelativeName.RelativeName;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Do a full path open with no containing directory */
|
|
|
|
RelativeName.ContainingDirectory = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now open the directory name that was passed in */
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&NtPathU,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
RelativeName.ContainingDirectory,
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
DELETE | FILE_READ_ATTRIBUTES,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
|
|
|
|
FILE_NON_DIRECTORY_FILE |
|
|
|
|
FILE_OPEN_FOR_BACKUP_INTENT |
|
|
|
|
FILE_OPEN_REPARSE_POINT);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* Check if there's a reparse point associated with this file handle */
|
|
|
|
Status = NtQueryInformationFile(FileHandle,
|
|
|
|
&IoStatusBlock,
|
|
|
|
&FileTagInformation,
|
|
|
|
sizeof(FileTagInformation),
|
|
|
|
FileAttributeTagInformation);
|
|
|
|
if ((NT_SUCCESS(Status)) &&
|
|
|
|
(FileTagInformation.FileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) &&
|
|
|
|
(FileTagInformation.ReparseTag != IO_REPARSE_TAG_MOUNT_POINT))
|
|
|
|
{
|
|
|
|
/* There is, so now try to open it with reparse behavior */
|
|
|
|
NtClose(FileHandle);
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
DELETE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_DELETE |
|
|
|
|
FILE_SHARE_READ |
|
|
|
|
FILE_SHARE_WRITE,
|
|
|
|
FILE_NON_DIRECTORY_FILE |
|
|
|
|
FILE_OPEN_FOR_BACKUP_INTENT);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* We failed -- maybe whoever is handling this tag isn't there */
|
|
|
|
if (Status == STATUS_IO_REPARSE_TAG_NOT_HANDLED)
|
|
|
|
{
|
|
|
|
/* Try to open it for delete, without reparse behavior */
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
DELETE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_READ |
|
|
|
|
FILE_SHARE_WRITE |
|
|
|
|
FILE_SHARE_DELETE,
|
|
|
|
FILE_NON_DIRECTORY_FILE |
|
|
|
|
FILE_OPEN_FOR_BACKUP_INTENT |
|
|
|
|
FILE_OPEN_REPARSE_POINT);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (!(NT_SUCCESS(Status)) &&
|
|
|
|
(Status != STATUS_NOT_IMPLEMENTED) &&
|
|
|
|
(Status != STATUS_INVALID_PARAMETER))
|
|
|
|
{
|
|
|
|
/* We had some critical error querying the attributes, bail out */
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
NtClose(FileHandle);
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* It's possible that FILE_OPEN_REPARSE_POINT was not understood */
|
|
|
|
if (Status == STATUS_INVALID_PARAMETER)
|
|
|
|
{
|
|
|
|
/* Try opening the file normally, with reparse behavior */
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
DELETE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_DELETE |
|
|
|
|
FILE_SHARE_READ |
|
|
|
|
FILE_SHARE_WRITE,
|
|
|
|
FILE_NON_DIRECTORY_FILE |
|
|
|
|
FILE_OPEN_FOR_BACKUP_INTENT);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* This failed too, fail */
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Maybe we didn't have READ_ATTRIBUTE rights? */
|
|
|
|
if (Status != STATUS_ACCESS_DENIED)
|
|
|
|
{
|
|
|
|
/* Nope, it was something else, let's fail */
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Let's try again, without querying attributes */
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
DELETE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_DELETE |
|
|
|
|
FILE_SHARE_READ |
|
|
|
|
FILE_SHARE_WRITE,
|
|
|
|
FILE_NON_DIRECTORY_FILE |
|
|
|
|
FILE_OPEN_FOR_BACKUP_INTENT |
|
|
|
|
FILE_OPEN_REPARSE_POINT);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* This failed too, so bail out */
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Ready to delete the file, so cleanup temporary data */
|
|
|
|
RtlReleaseRelativeName(&RelativeName);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, PathBuffer);
|
|
|
|
|
|
|
|
/* Ask for the file to be deleted */
|
|
|
|
FileDispInfo.DeleteFile = TRUE;
|
|
|
|
Status = NtSetInformationFile(FileHandle,
|
|
|
|
&IoStatusBlock,
|
|
|
|
&FileDispInfo,
|
|
|
|
sizeof(FILE_DISPOSITION_INFORMATION),
|
|
|
|
FileDispositionInformation);
|
|
|
|
NtClose(FileHandle);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* Deletion failed, tell the caller */
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Tell the caller deletion worked */
|
|
|
|
return TRUE;
|
1999-04-14 00:52:19 +00:00
|
|
|
}
|
2000-01-11 17:32:13 +00:00
|
|
|
|
|
|
|
/* EOF */
|