DVD-RAM USERS ONLY ver.11.0
FFCをDVDRAMに対して使うとファイルが壊れるよ
>>19 ヘッド移動回数が多くなるから、遅くなるのだと思う
ファイル転送終了>書き込みチェックのためヘッド移動>チェック完了後、次ファイル書き込み位置にヘッド移動>・・の繰り返しではないかと
23 :
不明なデバイスさん:04/10/23 21:38:31 ID:qu89aaz1
>>20 圧縮に時間がかかるしすでにjpgだし・・・
>>21 やらなくてよかった!
>>22 たぶんそのてのものでしょうね、しかしまさか倍もかかるとは
倍ですんだという方かな
んー、最もポピュラーなzipが一番取り回しがいいと思うが
そこで無圧縮ZIPですよ。
意味ねえー!
zipで固めて解凍するとタイムスタンプがズレるのが嫌
>>21 >FFCをRAMに対して使うとファイル壊れる
何か根拠あるのか?ソースキボンヌ
実際に壊れた
それとは別に報告もある
今は直ってるかどうかは知らない
今さらながら、
SW-9573-C ≒ LF-D721 = 5倍速RAM 殻:○
SW-9583-C ≒ LF-D621 = 3倍速RAM 殻:×
だという事に気づいた漏れ。末尾のCはCartridgeかと思ってたら、違うようだ。
最近の松下の型番法則はワケワカラン。詳しい人解説おながいします。
>>31 糞メモリ積んでるマシンに1票。
うちは未だにi850eでPC800-40wECC(Samsung製)のメモリ使ってるけど、
メディア側に原因が無い限り、FCC使って一度もエラーなんぞ吐いた事無いぞ。
zip自体が弱いんじゃなかったっけ?
修復用のアプリも出回ってたりする。
p2pなんかではパリティ付加できるRARが使われてるよね。
うちはいつもFFCでコピーするけど壊れたことないなあ
報告ってどこなんだ?
>>33 エラーは出ないんだ
見かけ正しくコピーされてる
でも、ファイルを開くと壊れている
>>36 それはメモリやIDEのドライバが腐ってる場合などに起こる現象だな。
昔はよくRAIDカードと一部のHDDとの組み合わせなどでも発生した。
ソフトの前に自分の環境を疑え。
そういう原因で起こる可能性は否定しないが、
ソフトのバグでも起こる
君の主張は何の意味もない
何か頭の悪い粘着が一匹居るな。
そんなバグならもっと話が大きくなっている筈。
何でもアプリのせいにするなよ貧乏人。
↑否定しないという意思があるなら、環境やその報告とやらのソース元を公開してから言ってくれ。
そっちの主張(愚痴)こそ何の意味も無いぞ。情報として無益だ。
> リムーバブルメディアや仮想ドライブへの読み書きには対応しているか?
> 対応しています。ただしエクスプローラなどで正常に動くのにFireFileCopyだと不具合が出るような場合(たまにあります)は、ドライバを最新版にしてみてください。
この辺りの話だと思う
問題にならないのは、FFCとDVDRAMの両方がマイナーで、
かつ問題の出ない環境もあるだろうから
http://pc5.2ch.net/test/read.cgi/software/1091694959/ FFCのスレもあった
RAMで検索すると報告がいくつか
速攻でメモリのせいにされてるけど
まあ、ある意味信者の総本山だから仕方ない面もある
このスレにも信者が紛れ込んでる気がする
うちのメモリはmemtestをパスしているが
で、本当にメモリのせいだったとして
それでも普通のコピーで問題ないのにFFCでのみ問題が
発生するならば、やはり危険なソフトだと言わざるを得ない
少なくとも大事なファイルの移動には使うべきではない
どうせどうでもいい画像ファイル
>>43 「自分(の環境)は悪くない、ソフトが悪い」と頭から決めてかかっていて、具
体的な不具合報告(ハード/OS/常駐ソフト等の環境、再現方法、実際に壊れた
データなどの詳細情報)がないんじゃ、ただの中傷文でしかないな。
# 「ここにも信者が紛れ込んでる」なんで被害妄想もいいところ。
そんなレスしかかけないんじゃ、どこにいっても誰も相手にしてくれないよ。
凄い勢いで相手にされてる気もする
信者にとって痛い部分に触れちゃったのね
ちなみに、壊れたファイルの様子は、
同じデータが何度も繰り返して現れる
サイズは同じ
mp3データだったので、聞いてるとループして面白かった
いかにもバッファの取り扱いに失敗してる感じだったけど、
遅延書き込みとかの絡みを考慮してないのかもしれない
IDが変わる前に最後のカキコ。
>>41 >問題にならないのは、FFCとDVDRAMの両方がマイナーで、
>かつ問題の出ない環境もあるだろうから
FFC+RAMの組み合わせがマイナーなのはともかくとして、
「問題を出してる環境の人間が僅かであり、さらに再現性等について言及できるスキルもないため」
の間違いだな。
>>46 バッファを小さくしてやってみそ
8Mとか16Mで
理由は分からんけどうちはそれで回避出来てる
えっちぃな画像がしこたま入ったフォルダw
最初200Mでやったらほとんどの画像がぶっ壊れたが徐々にサイズ落としたらなんとかなった
凄い勢いで相手にされてる気もする
相手にされてるっつーか呆れられてる
まぁ信者を連発するあたりよほど癇に障ったのかな
FFCはそんなに特殊なことをしている訳でもなくて、
使ってる機能はwindowsの標準的なものを使っている
自前でバッファを用意してるくらい
で、そのバッファが曲者で、RAMの遅延書き込みとの
連携がうまく行かないと失敗する
具体的には、コピー元からバッファへコピー
バッファからRAMへコピー
windowsはコピー終了を返すが実際にはまだ書き込まれていない
でもFFCはバッファへ次のコピーの為のデータを転送
windowsはさっきのコピーの遅延書き込みを実際に開始
でも書き込まれるのは既に書き換わったデータ
というようなメカニズムで壊れるのではないかと
それだと、バッファを小さくすると直る理由が説明できないけど、
うまい具合に実メモリ上の違う場所にバッファが切られるのかもしれない
まあ、リスクに怯えながら使う義理は全くないので、
FFCを捨てるのが最良策
そもそも大きいファイルならコピー時間は転送速度律速で
何を使っても同じだし、細かいファイルを大量にコピーする
シチュエーションが希
まぁ漏れは両方の愛用者だが痛い部分って言われても(w
マイナーな環境の更にマイナーなヤシかわいそうとしか言えない
そもそも漏れが保存するのはRAMばっかりで、全部大切なデータで常時使う
壊れてたら残念では済んでないよ
そう言う意味では不愉快ではあるな。気が済んだかな?
確実に動作する環境の人はFFCを便利に使っていればよろしい
ごく普通の話だ
但し、環境によっては結構な確率でファイルが壊れるので、
DVD-RAMのスレでその危険性を指摘するのは極めて有益
>>21の
> FFCをDVDRAMに対して使うとファイルが壊れるよ
を100%壊れると理解してしまったんだろうな。
「FFCをDVDRAMに対して使うとファイルが壊れることがあるよ」
に訂正しておく
リスクを勘案して使うかどうか決めるのは各ユーザの判断なので、
信者各位は無用な勧誘をせぬこと
最近になってFFCのこと知ったんだけど壊れる可能性があるとはおもわなかった。
使うとき気を付けよう・・・。
もう移動とかコピーにFFC使うのが癖になってるからな・・・。
>52
IDEケーブルとかが糞なんではないか?
他のメディアで試してほしい気がするが
もちろんライティングソフトで書き込みでなく
パケットライトでドラッグ&ドロップで書き込みね
パケットライト?
遂にFFCを知らないFFC儲が現れたか
結局アンチかよ
何かにつけて信者信者いうヤシは全く信用できない
つーかCRCチェックをすればいい話だろ
普通は移動後やコピー後はするだろ?
どうもFFCを人に勧めるのが気にくわないみたいね
で、実際に使ってる人が不愉快になってる(当たり前だが)
そういう微妙なすれ違いがあるね
xcopyばんじゃーい
コマンドラインなんで人には勧めないけどな‥
>>57 必要な機能なんだからオプションででも装備されないかね?
FFC儲は移動やコピーの後に当然のようにCRCチェックを
していることを白状しました
FFCを使おうが使うまいが当然の作業だ
おれなんかXCOPYでも使ってたしR焼きにも使ってる
泣いたことない椰子には分からん行為だろうがな・・
FFCでファイルが壊れたことない椰子には
その危険性が理解できないのと同じ
よくしらんので検討違いなんだろうが
DVDRAMの自動ベリファイはなにしてるの?
それでFFCのコピーミスは回避できないの?
あれはドライブ内蔵のキャッシュ内のデータと書き込んだデータとでのべリファイだから
ドライブに入って来る前の段階のどこかで何らかデータが崩れてしまった場合は無意味
なるほど、はやり書き込み完了後に処理元と処理先を比較した方が良さそうだね。
メディアを問わず特に大事なファイルを処理したあとは。
>>62 >>63の通りだが?
色んなヤシがいるから、普通とまでは言わないが、PC弄ってるヤシなら通じる話だと思うがな
漏れもメモリが糞だった為に気がついたら色んなデータが死んでた事があった。
それ以降は焼き時にはベリファイはもちろんだが、素のコピーでデータ保存なんかでは必ずcrcチェックはする
>>62が非常に素人臭い
というかアンチっぽい割にFFCをそんなに信用してたのか(w