我的想法是使用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)
常量来自各种MSDN和pinvoke.net来源。
如果我在所有子文件夹上递归调用上面的代码,它最终会导致共享冲突,但是当CMD拒绝重命名时,它没有递归。
是的,我知道我可以尝试捕获异常。但是我想知道目录是否可以重命名以及我想要重命名目录的点是不一样。
修改
这个问题可能存在混淆的根源。我不关心权限;我关心文件锁。
答案 0 :(得分:3)
是的,我知道我可以尝试抓住 例外。但重点是 我想知道目录是否可以 重命名和我想要的点 重命名目录不是 相同。
在我看来,这是一个造成竞争条件的设计问题。如果您先检查并稍后重命名,如果之前的检查有效,您将无法知道重命名的时间。
答案 1 :(得分:1)
未经测试,但这应该有效:
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
这将“请求”文件夹的读写权限,而不实际重命名任何内容。
编辑:上述内容并没有达到我想象的效果,请参阅Stephen的评论。
如果这不起作用,或许尝试使用相同的文件名重命名文件将触发安全异常,而不会实际做任何破坏性的事情(尽管它可能会“触摸”目录)。 / p>