アカウント名:
パスワード:
UNIXではコピー先に書き込みパーミッションの落とされたファイルがあるときに、勝手にパーミッションを立てて更新したりはしないと思うんだけど、Windowsでも間違って書き込まれたくないから読み取り専用属性を立てるんじゃないの? 上書きしていいかどうかは状況によるのでは?
BackupReadやBackupWriteに言及していないのは非同期I/Oをサポートしていないからか? しかし(公開APIでは)これ以外に読み書きの方法がないメタ情報もあるので、避けて通ることはできない。
WSLが第3のシンボリックリンク的な実装としてIO_REPARSE_TAG_LX_SYMLINKを導入した。
Vista以降ではCancelSynchronusIoという同期I/Oをキャンセルできる関数が追加された。
実際には、NT系ではゼロクリアされると仮定していい。別ドキュメントに根拠もある(Windowsのプロたるものドキュメントが相互矛盾している程度のことでうろたえてはならない)。ゼロクリアしたくないときはSetFileValidDataを使う。削除されたファイルの残骸かもしれないデータが読めてしまうのは重大なセキュリティ問題なので、この動作が変わることは考えづらい。SetFileValidDataもSeManageVolumePrivilegeを持つ(最初からボリューム全体を読み取れる)ユーザーにしか許可されていない。SetEndOfFileやSetFilePointerのドキュメントが保証を与えていないのは、Win9xではゼロクリアされなかったため。詳しくは白水氏(FastCopyの作者)のツイートを参照。
FSCTL_SET_ZERO_DATAはNT系では無駄に二重にゼロクリアするだけだし、Win9x系ではサポートされていないので、ゼロ初期化の目的で役に立つ場面はない。これは基本的にスパースファイルに穴を開けるために使うもの。
Vista以降ではGetFileInformationByHandleExでACLを無視したストリーム情報が取れるはずなので、これを使うべき。(18)を考慮しても、FindFirstStreamWがそもそもVista以降だしそれ以前のOSでもBackupReadがあるので非公開APIに出番はない。ていうかWin95時代から脳死状態でコピペを繰り返してるだけのSetEndOfFileやSetFilePointerのドキュメントの重箱の隅は異常に気にするくせにどうしてドキュメント化されていないAPIを平気で使うんだよ。
ぜひ元記事の方に指摘してあげてください。
NTをやっているなら、BackupRead, BackupWrite の存在まで含めて、記事の内容はすべて常識です。「もちろん知ってますよね?」っていう書き方になってるはず。少なくとも、NTFS は、ジャーナル付きのデータベースとみるべきで、項目の抽出には、ntfs.sysによるダンプしかない。書かれている内容を、商用データベースに置き換えてみれば、なるほど、「知らない奴は本番環境にさわらないでくれ」ってなるはず。
いやほんと登さんにこれ教えた方がいいよ煽り気味の書き込みだけど内容は俺も勉強になった
>ていうかWin95時代から脳死状態でコピペを繰り返してるだけのSetEndOfFileやSetFilePointerのドキュメントの重箱の隅は異常に気にするくせにどうしてドキュメント化されていないAPIを平気で使うんだよ
ここ俺も気になった。ただよく読むと彼は知ってて書いてると思う。NTFSはPOSIXサポートもあるしゼロクリアするのは最初から設計にあったの知らないわけない。要するに煽りスタイルあるいは炎上マーケティング的な何か。
プロならWindows95から10まですべてのバージョンに対応する必要があるから、これだけの可能性を考慮しろと書いてあるだけのような。NTFSだけ対応すればいいわけではないので、広い範囲で問題起きないBackupExecを持ち上げてるわけで。
可能性を考慮しろと言いつつUndocumented APIねぇ
というか、単純なファイルのコピーとファイルシステムをダンプするのをごっちゃにしてるだけのような。そら後者は難易度高いし、おっしゃる通りなところではあるが。例えば前者は属性まで必ず再現すべきものではないだろと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
ツッコミどころいろいろ (スコア:2, 参考になる)
UNIXではコピー先に書き込みパーミッションの落とされたファイルがあるときに、勝手にパーミッションを立てて更新したりはしないと思うんだけど、Windowsでも間違って書き込まれたくないから読み取り専用属性を立てるんじゃないの? 上書きしていいかどうかは状況によるのでは?
BackupReadやBackupWriteに言及していないのは非同期I/Oをサポートしていないからか? しかし(公開APIでは)これ以外に読み書きの方法がないメタ情報もあるので、避けて通ることはできない。
WSLが第3のシンボリックリンク的な実装としてIO_REPARSE_TAG_LX_SYMLINKを導入した。
Vista以降ではCancelSynchronusIoという同期I/Oをキャンセルできる関数が追加された。
実際には、NT系ではゼロクリアされると仮定していい。別ドキュメントに根拠もある(Windowsのプロたるものドキュメントが相互矛盾している程度のことでうろたえてはならない)。ゼロクリアしたくないときはSetFileValidDataを使う。削除されたファイルの残骸かもしれないデータが読めてしまうのは重大なセキュリティ問題なので、この動作が変わることは考えづらい。SetFileValidDataもSeManageVolumePrivilegeを持つ(最初からボリューム全体を読み取れる)ユーザーにしか許可されていない。SetEndOfFileやSetFilePointerのドキュメントが保証を与えていないのは、Win9xではゼロクリアされなかったため。詳しくは白水氏(FastCopyの作者)のツイートを参照。
FSCTL_SET_ZERO_DATAはNT系では無駄に二重にゼロクリアするだけだし、Win9x系ではサポートされていないので、ゼロ初期化の目的で役に立つ場面はない。これは基本的にスパースファイルに穴を開けるために使うもの。
Vista以降ではGetFileInformationByHandleExでACLを無視したストリーム情報が取れるはずなので、これを使うべき。(18)を考慮しても、FindFirstStreamWがそもそもVista以降だしそれ以前のOSでもBackupReadがあるので非公開APIに出番はない。ていうかWin95時代から脳死状態でコピペを繰り返してるだけのSetEndOfFileやSetFilePointerのドキュメントの重箱の隅は異常に気にするくせにどうしてドキュメント化されていないAPIを平気で使うんだよ。
Re: (スコア:0)
ぜひ元記事の方に指摘してあげてください。
Re: (スコア:0)
NTをやっているなら、BackupRead, BackupWrite の存在まで含めて、記事の内容はすべて常識です。
「もちろん知ってますよね?」っていう書き方になってるはず。
少なくとも、NTFS は、ジャーナル付きのデータベースとみるべきで、項目の抽出には、ntfs.sysによるダンプしかない。
書かれている内容を、商用データベースに置き換えてみれば、なるほど、「知らない奴は本番環境にさわらないでくれ」ってなるはず。
Re: (スコア:0)
いやほんと登さんにこれ教えた方がいいよ
煽り気味の書き込みだけど内容は俺も勉強になった
Re: (スコア:0)
>ていうかWin95時代から脳死状態でコピペを繰り返してるだけのSetEndOfFileやSetFilePointerのドキュメントの重箱の隅は異常に気にするくせにどうしてドキュメント化されていないAPIを平気で使うんだよ
ここ俺も気になった。
ただよく読むと彼は知ってて書いてると思う。NTFSはPOSIXサポートもあるしゼロクリアするのは最初から設計にあったの知らないわけない。要するに煽りスタイルあるいは炎上マーケティング的な何か。
Re: (スコア:0)
プロならWindows95から10まですべてのバージョンに対応する必要があるから、これだけの可能性を考慮しろと書いてあるだけのような。
NTFSだけ対応すればいいわけではないので、広い範囲で問題起きないBackupExecを持ち上げてるわけで。
Re: (スコア:0)
可能性を考慮しろと言いつつUndocumented APIねぇ
Re: (スコア:0)
というか、単純なファイルのコピーとファイルシステムをダンプするのをごっちゃにしてるだけのような。
そら後者は難易度高いし、おっしゃる通りなところではあるが。
例えば前者は属性まで必ず再現すべきものではないだろと。
Re: (スコア:0)
状況によるんなら状況を判断する材料を提供しないと意味ないだろ
読み取り専用属性というフラグ一つで、ファイル内容への書き込み禁止フラグとファイルそのものの削除禁止フラグという2つの意味をもたせている設計ミス