前のメッセージ
一覧 次のメッセージ 
■Topic: [2338] ファイル送受信の問題 dai (^_^)
■Reply: [2532] Re:2531)ファイル送受信の問題 れな (^_^)
ご回答どうもありがとうございます。 しかしながらあまり愉快とは言えない内容ですね。
以下1,000,000,000などの10進数表記をg、1,073,741,824などの2進数型をGで表記することにします。
>0バイトのファイル(CGIに使う空のデータファイル等)は有っても、000000000バイトのファイルは有りませんよね。
>サイズ不明として扱われると思うのですが。
>空き容量−サイズ不明=計算不可能(エラー)
しかしながら、2gBでもこの計算エラーが出ずにちゃんと送信できることがあります。 そしてエラーが出た場合でも、私が書いているエラー回避方法、つまりHDD空き容量を4GBで割った余りを2gB以上にすれば転送できます。
ですから、サイズ不明で計算不能なのではなく、ちゃんと計算されていると思われます。
私はICQのプログラムの中身のことはわかりませんが、実際転送をやってみて実証しています。
>用意されているエラーメッセージが限られている事は、ICQのプログラムをリソースエディタで見ると解りますよね。
>計算不可能ではなく、用意されているエラーメッセージの中に有る空き容量不足と同じエラーメッセージが出ているだけと思います。
>
>>先ほどもICQでのファイル受信をやり始めたのですが、
>>そのとき、受信側のHDD実容量は46,10*.***.***バイト(プロパティでチェック、*は書き留めず)で、
>>転送ファイル合計サイズは約4GBでICQには23.87MBと表示されましたので、4GB+23.87MBでしょうから、4,294,967,296ぐらいとなるはずです。
>>この場合、1G桁以下での計算であれば、HDD容量エラーになるはずですが、問題無く転送されています。
>
>実際のファイルサイズ(バイト)は?
4GB+23.87MBですから、4,294,967,296ぐらいと書いた通りです。 23.87MBは丸めたサイズでしょうが、計算上は切り捨てもしくは切り上げされた分は無視しても問題ないと思いますが?
>1つのファイルのサイズですか? 複数の総ファイルサイズですか?
転送リクエスト1ラインの総ファイルサイズです。 ファイルが一つであれ、複数ファイルであれ、転送の窓に表示されるファイルサイズにのみ依存しますから、これも計算には関係がないはずです。
>「2,000,000,000バイトで転送不可になること」は、どうして矛盾なのですか?
私が2gBのファイルが転送が不可になる場合とそれを回避するやり方を書いたように、単純なバイト数の10桁目以上が無視されるという説では上手く解釈できないのです。
>2,000,000,000バイト、10桁目の「2」が無視されていると言う事で、逆に9桁説の証明になると思います。
転送エラー(計算エラー)が回避できるということで証明にはなりません。計算不可能でのエラーならば、HDD容量を変えることでエラー回避はできません。
>4G(4,294,967,296バイト)でオーバーフローするとしたら
>2,000,000,000バイト(1.9G弱)は 4G未満なのに「2,000,000,000バイトで転送不可」で
>「4Gでオーバーフローする」の方が矛盾してると思います。
だから、HDDの空き容量をICQが認識できるのは4GBまでで、4GB超えたら(例えば4.5GB)0.5GBとして認識され、10GBならば2GBとして認識される。 そして転送ファイル容量も同様で、それらのHDD認識容量とファイル認識容量を比較し、HDD容量の方が大きければ転送可能と判断されるのです。
2bBで転送エラーは既に書いたようにHDD認識容量が2gB以下となる場合のみです。
>私には、この4GBの根拠が解らないのですが…
私もICQの開発者でもありませんし、プログラムを解析したこともありませんから、そんなことは知るはずもありませんし、どうでも良いことです。
ただ、私は以前にれなさんの777番は読みましたし、実際にGBオーダーのファイルを何度も転送する上で、エラー回避の方法を探ってきた結果が4GBなのです。
でも私の知る中学校(たぶん)レベルのコンピュータプログラムの知識から言えることは2進数を基本とするプログラムならばオーバーフローさせるときでも1,000,000,000Bという2進数では中途半端な数を限界値にするよりは4GB(=4,294,967,296B)もしくは1GB(=1,073,741,824B)の方が自然だということですね。
>この数字は、4Gでオーバーフローするとして、27Gは4Gで6回割ることが出来るから6でしょうけど。
? 割り算のした結果は6あまり3GBけど、6は意味はないのですけど。
>空き容量27Gでオーバーフローした4Gの残り23Gが、まだオーバーフローしているので更に4Gの残り19G..........と
>オーバーフローしない数字まで繰り返され、4G未満の数字を報告するという事ですか?
そういうことです。
>記事No.[777]に転載した内容は、調べて下さった方が居て、テスト結果は実際の正確な数字です。
>>テスト
これは偶然にも4GBでやった場合でも合致するため、試験した方が誤解したのだと思われます。
>でも、転送ファイルサイズ4G以下の
>「1,000,000,000バイト」「2,000,000,000バイト」「3,000,000,000バイト」「4,000,000,000バイト」が
>エラーになる件は、成り立ちませんよね?
それは違います。説明したように必ずエラーになるのではないのです。エラーになることがあるという例を示したのは単に1gBでオーバーフローしたのち計算されるのではないという反証の為です。
>それに、この掲示板に書く人のサイズは、みんな数十ギガバイトや数百メガバイトとアバウトですよね?
>正確な数字で、もっと沢山のデータが集まらないと、判断できませんね。
私がちゃんと正確な数字を書いているでしょう。 この前の転送例でも***で表記した部分など、0であっても9であっても何の違いもありません。 「もっと沢山のデータ」などと言う前に私が示した実験例をきちんと解析して、ご自身でも実験してその結果(特に私の仮説に矛盾するもの)を示すべきでしょう。
>私は、どちらも違うように思えてきました。
れなさんは私の出した実証結果を検証もせず、思い込みだけで私の仮説を否定されるようですが、非常に失礼なことです。
私はプログラムを解析したこともありませんから、絶対正しいとは言い切ることはできませんし、エラー発生のメカニズムについてまだ不明なこともあります。しかし、777番で紹介されたことを今まで無条件に信じるあまり、無理やり私の仮説に対していちゃもんをつけてきたように見えます。
私としては私が考えるエラー発生メカニズムを検証してみて、矛盾が生じる、それなら上手く行くという反応は、こちらにもエラー回避術を考える上でありがたいのですけどね。