0

私の考えは、kernel32のCreateFileを使用して、共有違反をチェックすることです。CMDから名前変更コマンドを発行しているときにProcessMonitorでファイルシステムのアクティビティを監視したため、これは機能すると思います。最後のアクティビティは、共有違反が発生した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が名前の変更を拒否した場合、再帰しませんでした。

はい、私は例外を捕まえることができることを知っています。しかし、ディレクトリの名前を変更できるかどうかを知りたいポイントと、ディレクトリの名前を変更したいポイントは同じではありません。

編集：

この質問には混乱の原因があった可能性があります。私は許可には関心がありません。ファイルロックが気になります。

4

2 に答える 2

3

はい、例外をキャッチしようとするだけでよいことはわかっています。しかし、ディレクトリの名前を変更できるかどうかを知りたいポイントと、ディレクトリの名前を変更したいポイントは同じではありません。

私の意見では、これは競合状態を引き起こす設計上の問題です。最初にチェックして後で名前を変更すると、以前のチェックが有効であった場合に名前を変更した時間がわかりません。

于 2009-06-29T17:09:38.100 に答える
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

これにより、実際に名前を変更することなく、フォルダーに対する読み取りおよび書き込みアクセス許可が「要求」されます。

編集：上記は私が思っていたことをしません。以下のスティーブンのコメントを参照してください。

これが機能しない場合、おそらく同じファイル名でファイルの名前を変更しようとすると、実際には破壊的なことを何もせずにセキュリティ例外がトリガーされます (おそらくディレクトリに「触れる」でしょう)。

于 2009-06-29T16:25:18.830 に答える