Fire File Copy Part12

**名無しさん＠お腹いっぱい。** · 2014/07/14(月) 17:44:53.02

前スレ
Fire File Copy Part11
http://anago.2ch.net/test/read.cgi/software/1311997940/

配布サイト　A-1 LABORATORY
http://www.k3.dion.ne.jp/~kitt/pc/sw/ffc/

**名無しさん＠お腹いっぱい。** · 2015/01/29(木) 08:50:49.63

このソフトで上書き確認のダイアログが出た時にコピー元のファイルを編集してから
上書きするとファイルが壊れてしまう
テキストを上書きする際にWinMergeで差異の編集をしてから上書きをする使い方をしてたんだけど

**名無しさん＠お腹いっぱい。** · 2015/01/31(土) 01:35:01.46

そりゃ処理中のファイルをいじくれば壊れるのなんて当たり前だろ
そんな意地悪な使い方するなよ
処理中のファイルはいじらないなんて基本だろう
エクセルやワードのファイルを既に開いておいてさらに開こうとすると警告されるけどそれを無視して開いて編集するのと同じだよ
どうなるかわかるでしょ

**名無しさん＠お腹いっぱい。** · 2015/01/31(土) 01:59:18.76

まあ順番的にWinMergeチェック->更新->コピーしろよとは思う

**名無しさん＠お腹いっぱい。** · 2015/01/31(土) 02:30:04.11

>>172
エクセルとかの場合は確かにそうなんだけどさ
コピーが一時停止している状況で尚且つファイルの排他制御も行われておらず
ダイアログでそのファイルを他のプログラムで開ける選択肢まで用意されていたら
感覚的には大丈夫だと思ってしまうのが普通じゃない?
windowsのエクスプローラのコピーの場合は問題無いし

上書き確認より先にメモリに展開して読み直したりもしてないから
壊れてしまうんだろうけど
ファイルのロックや書き換えの監視ぐらいは簡単にできるのだから
おそらく想定していなかったバグなのだと思う

**名無しさん＠お腹いっぱい。** · 2015/02/04(水) 23:30:31.81

そうだな、馬鹿なユーザも使用することを想定しなかった不具合だな

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 00:22:13.20

バグだっ！て騒いだところでもう更新されないんだから
自分で工夫するしかないでしょ
特にこのケースは単に正しい手順で更新すれば良いだけだしな

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 01:37:46.64

エラー処理がまったく行われていないってのは結構致命的なバグだよ
ハッシュチェックによるベリファイがONでも正常なファイルと見なされる
昔のスレにも「ファイルが壊れた」「メモリが悪いだけ」ってやり取りがいくつか有ったが
おそらく大量のファイルのコピーの間に排他制御の問題で壊れてしまったものも有ったんだろう

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 01:51:12.98

>>178
お前にとっては致命的でも他の人はそうでもないんだろ
そもそも致命的なら過去に報告が出てそうだけどな

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 18:37:19.24

処理中に処理対象のファイルをいじる方が悪い

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 23:27:25.39

逆にそういう使い方しても問題ないソフトあったら教えてね

**名無しさん＠お腹いっぱい。** · 2015/02/05(木) 23:39:11.90

具体的に壊れるってなんなんだろう
上書き確認した時に取得したファイルハンドルで処理しようとして
更新されたコピー元のファイルを処理しそこなったとかだろうか
取得したファイルハンドルが無効になっていたらエラーになりそうだけど

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 00:23:05.03

UNICODE版4.9.1で試してみたけどファイル末尾にゴミが付いたり末尾が切れたりする。
テストに使ったのはテキストファイル。
上書き確認が出たときに開いて
数行削る->コピーファイルにゴミが付く
数行増やす->コピーファイルの末尾が切れる

コピー前に転送バイト数を保存するから上書き確認で中断中に
ファイルを変更すれば変更後の内容を変更前のバイト数コピーするってことじゃないかと。
ベリファイONしていてもエラーにならないのはあくまでも転送した
データが正しく書き込まれたか確認しているからだろうと予想。
コピー後ファイルのサイズは編集前と同じだから編集によって
サイズが変わらなければ問題ないかもしれない。

個人的には致命的なバグでもなく普通の動作だと思うのだが。

つまりID:swxdJ+IS0が致命的にバグっている

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 01:44:07.79

普通に explorer なら壊れないし、それが普通。
仕様バグを強引に擁護する信者共がキモいw

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 11:06:55.23

バグって行ってるヤツって、設定でファイルの断片化はどうしてるん？

対象ファイルに関しては処理開始時に書込み制限をした方が本来は良いんだろう
でも処理中に対象ファイルにアクセスしないように利用者が気をつければ良いのだから、致命的なバグではないな

まぁExplorerでも処理中(一時停止中でも)に対象ファイルに触るなんて普通やろうとは思わないから正直愚行だと思うな

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 11:18:05.42

Explorerも排他制御してないからコピー中にファイル編集できるんだけどこれもバグって言いそうだな

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 12:01:12.67

批判されている訳でもバカにされている訳でもないのに
何故ただのバグ報告をそこまでムキになって否定してるのか。
ファイルが編集できるか否かではなく
編集した場合に壊れたりエラー表示が無いのも問題なんだろう
大量のファイルのコピーをしている時に
ファイルが使用中なのに気付かなかったり意図せず編集されてしまう
うっかりミスをする事ぐらいあるかもしれないでしょう

**名無しさん＠お腹いっぱい。** · 2015/02/06(金) 12:09:26.74

エクスプローラーで試してみたらファイルがロックされているから
編集そのものが出来ないな

**名無しさん＠お腹いっぱい。** · 2015/02/10(火) 00:41:32.61

Win8.1 の Explorerで上書き確認ダイアログが出ている状態では、コピー元とコピー先はロックされない。
さらにダイアログが出ている間にコピー元ファイルを更新し、"ファイルを置き換える"を選んでも
当然正しく更新済みファイルでコピーされる。