如何在 VB.NET 中检查目录是否可以重命名?

发布于 2024-07-25 16:25:56 字数 1298 浏览 6 评论 0原文

我的想法是使用 kernel32 中的 CreateFile 并检查共享冲突。 我相信这会起作用,因为我在从 CMD 发出重命名命令时使用 Process Monitor 观察了文件系统活动,我知道该命令会失败,并且最后一个活动是失败的 CreateFile 调用,导致共享冲突。

这是有关呼叫的进程监视器信息。

Desired Access: Read Attributes, Delete, Synchronize
Disposition: Open 
Options: Synchronous IO Non-Alert, Open Reparse Point 
Attributes: n/a 
ShareMode: Read, Write, Delete 
AllocationSize: n/a

使用此 VB 代码,我生成了一个调用,该调用在 Process Monitor 中提供了相同的信息,但没有导致共享冲突。

CreateFile(theDirectoryPath, _
           FILE_READ_ATTRIBUTES Or DELETE Or SYNCHRONIZE, _
           FILE_SHARE_READ Or FILE_SHARE_WRITE Or FILE_SHARE_DELETE, _
           Nothing, _
           OPEN_EXISTING, _
           FILE_ATTRIBUTE_DIRECTORY Or FILE_FLAG_BACKUP_SEMANTICS _
               Or FILE_FLAG_OPEN_REPARSE_POINT, _
           Nothing)

这些常量取自各种 MSDNpinvoke.net 来源。

如果我在所有子文件夹上递归调用上述代码,最终将导致共享冲突,但是当 CMD 拒绝重命名时,它不会递归。

是的,我知道我可以尝试捕获异常。但是我想知道目录是否可以重命名的点和我想重命名目录的点并不相同。

编辑:

这个问题可能存在混乱的根源。 我不关心权限; 我关心文件锁。

My thought is to use CreateFile from kernel32 and check for sharing violations. I believe this will work because I watched the file system activity with Process Monitor while issuing a rename command from CMD that I knew would fail and the last activity was a failed CreateFile call that resulted in a sharing violation.

This is the Process Monitor information on the call.

Desired Access: Read Attributes, Delete, Synchronize
Disposition: Open 
Options: Synchronous IO Non-Alert, Open Reparse Point 
Attributes: n/a 
ShareMode: Read, Write, Delete 
AllocationSize: n/a

Using this VB code, I produced a call which gave the same information in Process Monitor but did not cause the sharing violation.

CreateFile(theDirectoryPath, _
           FILE_READ_ATTRIBUTES Or DELETE Or SYNCHRONIZE, _
           FILE_SHARE_READ Or FILE_SHARE_WRITE Or FILE_SHARE_DELETE, _
           Nothing, _
           OPEN_EXISTING, _
           FILE_ATTRIBUTE_DIRECTORY Or FILE_FLAG_BACKUP_SEMANTICS _
               Or FILE_FLAG_OPEN_REPARSE_POINT, _
           Nothing)

The constants are pulled from various MSDN and pinvoke.net sources.

If I call the above code recursively on all subfolders it will eventually cause the sharing violation, but when CMD refused to rename, it did not recurse.

Yes, I know I could just try and catch the exception. But the point at which I want to know if the directory can be renamed and the point at which I want to rename the directory are not the same.

EDIT:

There may have been a source of confusion in this question. I am not concerned with permissions; I am concerned with file locks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

我的影子我的梦 2024-08-01 16:25:56

是的,我知道我可以尝试抓住
例外。 但此时此刻
我想知道目录是否可以
重命名和我想要的点
重命名目录不是
一样。

在我看来,这是一个造成竞争条件的设计问题。 如果先检查后重命名,如果之前的检查有效,您将不知道重命名的时间。

Yes, I know I could just try and catch
the exception. But the point at which
I want to know if the directory can be
renamed and the point at which I want
to rename the directory are not the
same.

In my opinion, this is a design problem that creates a race condition. If you check first and rename later, you will not know that the time of rename if your previous check was valid.

咆哮 2024-08-01 16:25:56

未经测试,但这应该有效:

Dim fp As New FileIOPermission(FileIOPermissionAccess.Write, "C:\myfolderpath")
Try
    fp.Demand()
Catch e As SecurityException
    Console.WriteLine("I can't rename this folder.")
End Try

这将“要求”文件夹的读写权限,而无需实际重命名任何内容。

编辑:上面的内容并没有达到我的预期,请参阅下面斯蒂芬的评论。

如果这不起作用,也许尝试使用相同的文件名重命名文件将触发安全异常,而不会实际执行任何破坏性操作(尽管它可能会“触及”目录)。

Untested, but this should work:

Dim fp As New FileIOPermission(FileIOPermissionAccess.Write, "C:\myfolderpath")
Try
    fp.Demand()
Catch e As SecurityException
    Console.WriteLine("I can't rename this folder.")
End Try

This will "demand" Read and Write permissions on the folder without actually renaming anything.

Edit: The above doesn't do what I thought it would, see Stephen's comment below.

If this doesn't work, perhaps attempting to rename the file with the same filename will trigger the security exception without actually doing anything destructive (though it will probably "touch" the directory).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文