Network Redirector Drivers 固有の動作

IRP_MJ_QUERY_INFORMATION
https://msdn.microsoft.com/ja-jp/library/ff549283(v=vs.85).aspx

Operation: Network Redirector Drivers
「A network redirector driver not based on RDBSS that receives an IRP_MJ_QUERY_INFORMATION request for FileAllInformation or FileNameInformation, must respond with the full "\server\share\file" path for the file name with a single leading backslash before the server name. This format for name information must be returned for a file accessed as a Universal Naming Convention (UNC) name (\\server\share\folder\filename.txt, for example) or a file located on a mapped drive (x:\folder\filename.txt, for example).」

FileNameInformation 対応が必要。

Dokan 0.6.0 は Windows 10 で動作?

先ほど、Windows 10 Insider Preview の、
Windows 10 Insider Preview (x86) - ビルド 10074 で試しました。

顧客案件なので詳細は明かせませんが、、、一応ふつうに動いていました。

製品版の Windows 10 でも一応、動いています。

共有アクセスモードの取り扱い

DokanNetでは、CreateFileに渡されるFileAccessが限定されています。Read, Write, ReadWrite

実はもっと沢山有って、DokanNetのCreateFileProxyから渡される情報を鵜呑みにしたのでは、はまってしまいます。

Generic Access Rights
https://msdn.microsoft.com/en-us/library/windows/desktop/aa446632(v=vs.85).aspx

File Access Rights Constants
https://msdn.microsoft.com/en-us/library/windows/desktop/gg258116(v=vs.85).aspx

詳しくはDokanNetのソースコードを見れば早いのですが、Query専用で開くCreateFileに対応できていません。

(FileAccess)0  ← これが欠けています。代わりにReadが来るので、場合によっては、共有違反扱いになります。
Read
Write
ReadWrite

例えば、GetFileSizeの実装として、CreateFileを使うと思うのですが、場合によっては、共有違反になり、ファイルを開くことができません。

できませんので、アプリによっては、とんでもない結果を招いたりします。例えば、WindowsのZipフォルダ機能では、Zipファイルが壊れたりします。。。

ファイル→新規作成で、盾フォルダだけになる件

DokanNetの場合、GetFileSecurityを実装すれば、通常フォルダのように、ファイル項目が出るようになります。

因みにFAT32のドライブに対してSDDLを調査した所、O:WDG:WDでした。ACL非対応といいつつも、さり気無くGetFileSecurityへ応答している所が。。。

O:WDG:WD

Owner = Everyone
Group = Everyone
DACL なし?
SACL なし?

Oplockについて

Dokanでは直接Oplockに関与する機会が無いのですが。。。 Windows 8 アプリ対策で必要になりそうな感じですので、少し勉強しました。

SDKとWDKの両方に、別々の情報が有ります。

ーーー
Oplock Semantics - Overview
https://msdn.microsoft.com/ja-jp/library/ff551011(v=vs.85).aspx

ーーー
Types of Opportunistic Locks
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa365713(v=vs.85).aspx

4種類のOplockが有ります。

• Level 1 Oplock -- 先読み許可、遅延書き込み許可。何でも許可。一人だけ取得可能。
• Level 2 Oplock -- 書き込み者なし。先読み許可。何人でも取得可能。
• Batch Oplock -- コマンドプロンプトのバッチファイル実行は、一行実行するごとにファイルを閉じる・開くを繰り返しやっている。この様を示して、バッチロック。Close/Openを送らない、省く事で最適化します。
• Filter Oplock -- 他者による書き込み＆削除を拒否。コンパイラがソースコードを読み取り専用でアクセスする様を示して、フィルタロック。

ーーー
Oplockは、共有モード(DenyRead, DenyWrite)とは別の概念です。

Samba3のドキュメントによると、
「Opportunistic lockingは、この機能に対して、実際には妥当ではない名前 である。この機能の真の利点は、クライアントサイドのデータキャッシングであり…」

ーーー
Breaking Opportunistic Locks
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa363786(v=vs.85).aspx

Oplockは一種の権利ですが、剥奪される可能性も有ります。

ーーー
Opportunistic Lock Examples
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa365436(v=vs.85).aspx

Oplockの動きについて書かれています。

ーーー
OSによって、使われるIOCTLコードが異なるようです。（詳細は未確認）

Windows 7, 8, 8.1

• FSCTL_REQUEST_OPLOCK (SDK) (DDK)

Windows Vista, XP, 2000

• FSCTL_OPBATCH_ACK_CLOSE_PENDING
• FSCTL_OPLOCK_BREAK_ACK_NO_2
• FSCTL_OPLOCK_BREAK_ACKNOWLEDGE
• FSCTL_OPLOCK_BREAK_NOTIFY
• FSCTL_REQUEST_BATCH_OPLOCK
• FSCTL_REQUEST_FILTER_OPLOCK
• FSCTL_REQUEST_OPLOCK_LEVEL_1
• FSCTL_REQUEST_OPLOCK_LEVEL_2

ーーー
折角Windows 8.1を使っているので、FileTestにてOplockをテストした所、

0x0000012C
ERROR_OPLOCK_NOT_GRANTED
Oplock 要求は拒否されました。

User modeからはダメなのだろうか。