hibara / AttacheCase

file/folder encryption software for Windows ( C++Builder2010 Project Files )

Home Page:http://hibara.org/software/attachecase/#new_version

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

実行中のexeファイルを暗号化できない

makoto-sato opened this issue · comments

実行中でもコピーや他のソフトでの圧縮などはできるので、アタッシュケース側の問題だと思います。
実行中のファイルにかぎらず、他の読み取り用に開かれているファイルも暗号化できないのではないかと思います。

ソースコードや、リファレンスなどを見たところ、おそらくですが、
ファイルを開いている所で fmOpenRead を渡しているところを、fmOpenRead | fmShareDenyWrite に変更すれば暗号化できるのではないかと思います。
また、自分自身の実行ファイルを開くとしているところでも fmShareDenyNone としていますが、 fmOpenRead | fmShareDenyWrite で開けるかと思います。
ただ、C++Builder を持っていないので、こちらで確認することができませんので、おそらくとしか言えません。
確認をお願いします。

ちょっと試して見たのですが、アプリケーションによるみたいですね。Wordファイルなどは、どうやっても暗号化はできませんでした(他のアーカイバーソフトでも「使用中」とのエラーが出ます)。

ただ、ファイル編集のShareを許すアプリケーションが開いている場合は、おそらく有効ですので、一応、そのオプションを次版の修正で追加してみたいと思います。

アタッシュケースのページのソースレベルの変更点のところ、 「fmShareDenyRead」を加えてみたになってますが、fmShareDenyWrite じゃないんですか。
また、依然として実行中のexeファイルを開けていませんね、ソースコードも fmOpenRead のみのままでしたし。

おそらくですが、Wordファイルは書き込み用、もしくは、読み書き用に開いているために、開けないんじゃないかと思います。
通常、書き込みをする場合は、他のアプリケーションでの読み取りも書き込みもさせないようにするはずですので。

んん? すみません、「実行中のexe」っておっしゃっているのは、アタッシェケースが吐き出す実行形式ファイルのことではなく、他のアプリケーションということでしょうか?(word.exeなど)。

ちょっと僕も、あまり現象を理解せずに修正してしまったのはまずかったですね。。。

すみません。きちんと検証し直してから、対処します。
いったんクローズを解除します。

すいません。説明不足でしたね。具体的には自作した常駐型アプリケーションのexeファイルです。
友人に渡すためにアタッシュケースで暗号化して渡していますので、その際に起動したまま暗号化しようとするとエラーになります。

一応、実行中のexeファイルは開けるようになりましたが、何か理由があって、fmShareDenyNone にしてるんでしょうか?

参考にしたページ
http://docwiki.embarcadero.com/Libraries/XE3/ja/System.Classes.TFileStream.Create

ご存知でしたら失礼ですが、サイトを見ると、fmShareDenyNone を指定した場合、読み込んでいる最中に、他のアプリケーションから同じファイルに書き込みが行われる可能性があり、データの整合性がとれなくなる可能性があります。
そうなってしまった場合、いざ復号してみたら、ファイルが壊れていたなんてことになりかねません。
しかも、fmShareDenyNone を指定すると書き込み中でも暗号化できてしまうと思うので、ファイルが壊れてしまったとしても、コンペアしない限り、実際に復号してファイルを開いてみるまで気付かないのではないかと思います。

読み込み操作だけならば、他のアプリケーションから開かれたとしても、内容が変わることはないので、データの整合性は失われません。
なので、fmOpenRead | fmShareDenyWrite と書いたのですが、fmShareDenyWrite では駄目なんでしょうか?

すみません・・・とくに理由はなく、すべてfmShareDenyNone にしました。
しいて言えば、アタッシェケースごときが、ファイルハンドルをがっちり掴んでいる理由もないかと思いまして。

でもたしかに、fmOpenRead | fmShareDenyWrite の方が良いかもしれませんね。

とはいえ、「ファイルの整合性」という意味では、アタッシェケースは、暗号化する前にいったんファイルリストを生成してから暗号化処理に入るので、そのファイルリスト生成時に(もちろんこの時点ではすべてのファイルハンドルを掴んでいるわけではありません)、ファイルやフォルダを移動させた時点で、暗号化ファイルの整合性はなくなり、ファイルは壊れます。

他のアーカイバーソフトなんかが、どんなふうにこの問題を回避しているのかは調査したことがないのでわかりませんが、アタッシェケース側が、そこまでしなくてはいけないソフトか?とも思うのです。

ということもあり、まあ、いいかなあという軽い気持ちだったんですが、たしかに一瞬とはいえ、fmOpenRead | fmShareDenyWrite としておいた方が厳密かもしれません。

次版で対応します。何度もすみませんです。

よろしくお願いいたします。

修正お疲れ様です。
ファイルの整合性の話ですが、ソースを軽く見たところ、暗号化中にファイルを移動させた場合、ファイルを開く所で例外が投げられるので、エラーメッセージが出て気づくことができると思いますので、このままでも大丈夫じゃないかと思います。ただ、現在のエラーメッセージでは移動させたのが原因とは気付かない可能性はありますが。
暗号化中にファイルが追加された場合は、暗号化ファイルに追加されたファイルが含められませんが、暗号化開始時に存在していなかったファイルなので、これも仕方がないと思います。