Cygwin:打开句柄时删除文件
Cygwin: Deleting file when handle is opened
我有一个我想删除的文件,它的句柄由系统进程持有,所以每次我尝试删除它时它都会给出 Access denied
但由于某种原因 cygwin 能够删除它。
我下载了 coreutils 并查看了 rm
可执行文件的源代码,发现它使用 unlink
函数来实现它。我创建了一个使用相同功能的小测试程序,但它仍然给了我 Access denied
。
然后我发现了这个 article 并且有人描述了 cygwin 如何能够删除如下文件:
Cygwin opens files always with all sharing flags
set, so a file opened by a Cygwin process should not result in a sharing
violation in another open call. The exception is the first NtOpenFile
in unlink_nt, which opens the file with FILE_SHARE_DELETE only to find
out if the file has an open handle somewhere else. In that case it gets
a STATUS_SHARING_VIOLATION, the next NtOpenFile will open the file with
all sharing flags set, and unlink_nt will try to delete the file or to
rename it, or to move it to the recycle bin, dependent on its path.
这是有道理的,所以我开始实施同样的事情。这是我的代码:
HANDLE file;
PIO_STATUS_BLOCK stat;
UNICODE_STRING myUnicodeStr;
RtlInitUnicodeString(&myUnicodeStr, L"C:\Program Files (x86)\TSU\bin\TSU.sys");
POBJECT_ATTRIBUTES attr;
InitializeObjectAttributes (attr, &myUnicodeStr, OBJ_OPENIF, NULL, NULL);
NtOpenFile(&file, MAXIMUM_ALLOWED, attr, NULL, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, FILE_DELETE_ON_CLOSE);
NtClose(file);
如您所见,我正在尝试打开设置了共享标志的文件,并且还使用了 FILE_DELETE_ON_CLOSE
,因为我关闭了句柄,我希望之后将其删除。
出于某种原因,我遇到的问题是 Segmentation Fault
(我使用的是 cygwin win10)。由于某种原因,很少调试表明问题出在 InitializeObjectAttributes
函数中。
P.S
我知道当文件的句柄被其他进程持有时删除文件不是最佳解决方案,但主要目标是以这种方式模仿 rm.exe
的行为。希望你能帮忙。谢谢。
在windows下并不总是可以删除文件。例如,当某些进程将此文件映射为图像时
如果尝试删除 运行 EXE 文件 rm.exe - 它首先调用 ZwOpenFile
with DesiredAccess = DELETE
, ShareAccess = FILE_SHARE_DELETE
and OpenOptions = FILE_OPEN_FOR_BACKUP_INTENT
. this is ok. than called ZwSetInformationFile
with FileDispositionInformation
- the DeleteFile
from FILE_DISPOSITION_INFORMATION
设置为 TRUE。此调用失败,状态为 STATUS_CANNOT_DELETE
。
文件系统 return STATUS_CANNOT_DELETE
完全来自 this 位置:
// Make sure there is no process mapping this file as an image.
if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
MmFlushForDelete )) {
DebugTrace(-1, Dbg, "Cannot delete user mapped image\n", 0);
return STATUS_CANNOT_DELETE;
}
比 rm.exe 再次尝试打开文件,已经有 OpenOptions = FILE_OPEN_FOR_BACKUP_INTENT | FILE_DELETE_ON_CLOSE
选项。但是这个调用当然会失败,同样是 STATUS_CANNOT_DELETE
。现在来自 this 点的错误:
// If the user wants to delete on close, we must check at this
// point though.
//
if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) {
Fcb->OpenCount += 1;
DecrementFcbOpenCount = TRUE;
if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
MmFlushForWrite )) {
Iosb.Status = DeleteOnClose ? STATUS_CANNOT_DELETE :
STATUS_SHARING_VIOLATION;
try_return( Iosb );
}
}
在此 rm.exe 之后再次调用 ZwSetInformationFile
already with FileRenameInformation
- where RootDirectory
from FILE_RENAME_INFORMATION
指向卷(文件位于)根目录(所以像 \Device\HarddiskVolume<N>\
和 FileName
指向回收站中的某个路径。结果文件实际上移动了但没有删除。rm.exe欺骗你
我有一个我想删除的文件,它的句柄由系统进程持有,所以每次我尝试删除它时它都会给出 Access denied
但由于某种原因 cygwin 能够删除它。
我下载了 coreutils 并查看了 rm
可执行文件的源代码,发现它使用 unlink
函数来实现它。我创建了一个使用相同功能的小测试程序,但它仍然给了我 Access denied
。
然后我发现了这个 article 并且有人描述了 cygwin 如何能够删除如下文件:
Cygwin opens files always with all sharing flags set, so a file opened by a Cygwin process should not result in a sharing violation in another open call. The exception is the first NtOpenFile in unlink_nt, which opens the file with FILE_SHARE_DELETE only to find out if the file has an open handle somewhere else. In that case it gets a STATUS_SHARING_VIOLATION, the next NtOpenFile will open the file with all sharing flags set, and unlink_nt will try to delete the file or to rename it, or to move it to the recycle bin, dependent on its path.
这是有道理的,所以我开始实施同样的事情。这是我的代码:
HANDLE file;
PIO_STATUS_BLOCK stat;
UNICODE_STRING myUnicodeStr;
RtlInitUnicodeString(&myUnicodeStr, L"C:\Program Files (x86)\TSU\bin\TSU.sys");
POBJECT_ATTRIBUTES attr;
InitializeObjectAttributes (attr, &myUnicodeStr, OBJ_OPENIF, NULL, NULL);
NtOpenFile(&file, MAXIMUM_ALLOWED, attr, NULL, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, FILE_DELETE_ON_CLOSE);
NtClose(file);
如您所见,我正在尝试打开设置了共享标志的文件,并且还使用了 FILE_DELETE_ON_CLOSE
,因为我关闭了句柄,我希望之后将其删除。
出于某种原因,我遇到的问题是 Segmentation Fault
(我使用的是 cygwin win10)。由于某种原因,很少调试表明问题出在 InitializeObjectAttributes
函数中。
P.S
我知道当文件的句柄被其他进程持有时删除文件不是最佳解决方案,但主要目标是以这种方式模仿 rm.exe
的行为。希望你能帮忙。谢谢。
在windows下并不总是可以删除文件。例如,当某些进程将此文件映射为图像时
如果尝试删除 运行 EXE 文件 rm.exe - 它首先调用 ZwOpenFile
with DesiredAccess = DELETE
, ShareAccess = FILE_SHARE_DELETE
and OpenOptions = FILE_OPEN_FOR_BACKUP_INTENT
. this is ok. than called ZwSetInformationFile
with FileDispositionInformation
- the DeleteFile
from FILE_DISPOSITION_INFORMATION
设置为 TRUE。此调用失败,状态为 STATUS_CANNOT_DELETE
。
文件系统 return STATUS_CANNOT_DELETE
完全来自 this 位置:
// Make sure there is no process mapping this file as an image.
if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
MmFlushForDelete )) {
DebugTrace(-1, Dbg, "Cannot delete user mapped image\n", 0);
return STATUS_CANNOT_DELETE;
}
比 rm.exe 再次尝试打开文件,已经有 OpenOptions = FILE_OPEN_FOR_BACKUP_INTENT | FILE_DELETE_ON_CLOSE
选项。但是这个调用当然会失败,同样是 STATUS_CANNOT_DELETE
。现在来自 this 点的错误:
// If the user wants to delete on close, we must check at this
// point though.
//
if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) {
Fcb->OpenCount += 1;
DecrementFcbOpenCount = TRUE;
if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
MmFlushForWrite )) {
Iosb.Status = DeleteOnClose ? STATUS_CANNOT_DELETE :
STATUS_SHARING_VIOLATION;
try_return( Iosb );
}
}
在此 rm.exe 之后再次调用 ZwSetInformationFile
already with FileRenameInformation
- where RootDirectory
from FILE_RENAME_INFORMATION
指向卷(文件位于)根目录(所以像 \Device\HarddiskVolume<N>\
和 FileName
指向回收站中的某个路径。结果文件实际上移动了但没有删除。rm.exe欺骗你