我的想法是使用 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 代码,我产生了一个调用,它在进程监视器中提供了相同的信息,但没有导致共享冲突。
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 拒绝重命名时,它并没有递归。
是的,我知道我可以尝试捕获异常。但是我想知道目录是否可以重命名的点和我想重命名目录的点是不一样的。
编辑:
这个问题可能存在混淆的根源。我不关心权限;我担心文件锁。