ホームに戻る > スレッド一覧 > 記事閲覧
[36] 100%のfileをフォルダごと移動させると%が落ちるのは何故?
日時: 2008/09/01 12:07
名前: ねここ ID:z12uw5OA

一度100%までDLしハッシュチェックも完了して100%だった物が、
フォルダを移動させ再び元の場所へ戻しハッシュチェックをすると
100%ではなく99.0%や99.7%とかになってたりします。

個別のファイルを見ると88.6%や中には0.0%になっている物もあります。
Windows上からプロパティで見ると容量は確保されていて、Jpgならば
画像もちゃんと表示されました。

元々はDLしたファイルを圧縮して保存しようとしたのですが、圧縮した
ファイルを展開してハッシュチェックを行うとこのような現象が起きました。
(その上で原因を突き詰めていったらフォルダの移動が原因のような…)

断片化も疑ったのですが個別にデフラグをかけても改善されませんでした。
%の低下は何度かフォルダ移動をしましたが常に同じ低下率(%)でした。

ご存知の方いましたら宜しくお願いします。
メンテ

(全部表示中) もどる スレッド一覧 新規スレッド作成

中身のどれかが見えない属性だったりとか? ( No.1 )
日時: 2008/09/02 02:11
名前: て2 ID:392wutrg

隠しファイル属性やシステムファイル属性が付いていると、
見えていない状態のままフォルダ内のファイルを「すべて選択」→コピー(圧縮や移動も含む)
とやってもそれらの見えないファイルまでは選択されていません。

結果、移動後や解凍後で欠けるファイルがあり、そういう状況になることは考えられます。

さらに、その欠けたファイルが存在するせいで、
ピースの関係上、バッチトレント内の連続したファイル(一覧で上か下)の一部再ダウンが行われる場合があります。(バージョンによる)


いかがでしょうか?
メンテ
いや、違うみたい… ( No.2 )
日時: 2008/09/02 23:15
名前: ねここ ID:I./R02Us

隠し属性やってみたけど変化無し。システムの方は見当たらなかった;;
ちなみに欠けるのは既に見えているファイルです。バージョンは0.70です。

あれから全体にデフラグやって断片化0にしたけど同じ現象が起きました。
どうやら断片化の可能性はなさそうです。

あと、この現象は幾つかの特定のフォルダにのみ発生するようです。
メンテ
特定のフォルダですか・・・ ( No.3 )
日時: 2008/09/03 04:32
名前: て2 ID:3kcU6WM2

特定の保存先から(へ)移動した場合ということですか? それとも特定のダウンデータ(フォルダ付き)ということでしょうか?

あと、
>隠し属性やってみた
???
えと、具体的に何を・・でしょうか?

>バージョンは0.70
なるほど、これまでに話題に上がっている再DLバグは大きく分けて3種類あるようなのですが、
私がお話した問題に関しては1.02に解決されたものですので 0.70では起りえますね。
確認ですが、その欠けた見えているファイルの上下(Bitのファイル一覧で)に、これなんだ?と思うような拡張子のファイル等はありませんか?


補足;とりあえずシステム属性というのは通常のファイルのプロパティでは存在すらしません。属性そのものが隠れています。
 システムに直接関わるファイル形式(sysはもちろん、bin、iniもその一つ)ではデフォルトで属性が付いています。


まぁ、ここまで書いといて何なのですが、フォルダごと移動させてたんですね・・・
すみません、完全に見落としてました。m(__;)m
それならシステムファイルが移動されない問題は無いです。はい。OTL

で、これにより追加の質問があるのですが、
そのトレントに含まれるファイルにdesktop.iniやThumbs.dbといった、自然に生成されるファイルは含まれていないですか?
自然に出来るものの宿命で、意図せずに内容が変わっている場合がありますから再ダウンすることになります。


う〜ん、どうだろう。。
メンテ
ファイルの境界とピースの境界を扱う部分が甘いのが理由では? ( No.4 )
日時: 2008/09/03 06:32
名前: Chi ID:1TitVu7A

ファイルの境界とピースの境界は多くの場合、不一致です。
強制的にピースの再チェックを行うと
その境界部分をファイルを越えて確認しない仕様になっているのでは
ないでしょうか。

私の使っているソフト(現バージョン)は、ファイルが全部100%の場合は、
移動やすり替えて、強制再チェックしても、ちゃんと100%になります。

が、一部、ダウンロードしないファイルが混じっていると、ヴァージョン
によって仕様が異なります。

メンテ
お手数お掛けします;; ( No.5 )
日時: 2008/09/03 09:18
名前: ねここ ID:TKota4zk

>て2さん
Bitで設定したDL先にDLしたフォルダ(中にファイルが入ってます)を
Bitで設定していない任意の場所へフォルダごと(ファイル入ってます)
移動させます。BitのDL先変更ではなくDLしたフォルダ(データ)の移動です。

特定のフォルダというのは大抵はハッシュチェック時に全ファイルが100%で、
移動させ再びBitで設定したDL先に戻してハッシュチェックをかけても
全ファイルは100%になるので、それ以外の一部のフォルダです。

と、思ったのですが調べてみると、欠けるフォルダ
(実質的には欠けるのは中のファイル)は結構あるみたいです。

あと稀にですが、一度移動させると戻してハッシュチェックをかけても
認識してくれない場合があります。

隠し属性は全てのファイルを表示するに切り替えて確認したという事です。
結果、フォルダの中には隠し属性ファイルはありませんでした。

謎なファイルはThumbs.dbがありますが、DLの時点でDL対象から外しています。
他には謎なファイルはありません。謎な名前のtxtはありますが、同じく
DL対象から外しています。

Thumbs.dbの自動生成による影響範囲は判りませんが、Thumbs.dbそのものを
越えて他のファイルの%にまで影響を与える事があるのでしょうか。
しかしフォルダ内を確認しましたが自動生成されるはずのThumbs.dbも
ありませんでした。

注意:私が言うフォルダとはBitのDL画面で表示された名前で保存されている
フォルダの事です(中のファイルも含みます)。ファイルというのは、
そのフォルダの中に保存されている個別のファイルを指しています。

>Chiさん
多分に私の知識不足ですが、ご容赦を。
ファイルの境界とピースの境界という言葉が判りません。
現バージョンというのは最新バージョンという事でしょうか。

DL完了後に移動させなければ全ファイルは100%になっています。
移動させ戻しハッシュチェックをすると個々のファイルの%が0.0%や87.6%に
なったりします。現バージョンで〜というのは、この現象が仕様である
という事でしょうか。

(DL対象から外しているファイルがあると、フォルダを移動させBitで設定した
DL先に戻してハッシュチェックをすると、DL対象になっているファイルの
%にまで影響を及ぼす、という事でしょうか)


以下参考

<フォルダ1>
A 99.0%
B 88.6%
C 0.0%

<フォルダ2>
D100.0%
E 0.0%
F 99.7%

フォルダごと移動しBitのDL先に戻してハッシュチェックをかけた後の物です。
フォルダ内の各ファイル(ABCやDEF)の合計であるフォルダの%は問題ではなく、
フォルダ内の各ファイル(ABCやDEF)の個々の%の減少に悩んでいます。
ABCやDEFは移動前は全て100%でした。
(なんとなく…なんとなく擦れ違いがありそうな気がしたので;;)
メンテ
お騒がせ致しました ( No.6 )
日時: 2008/09/03 12:39
名前: ねここ ID:TKota4zk

原因が未だに謎なのですが、現象の仕組みは判りました。
DLするファイルが複数あった場合に、DLするファイルを全てではなく
一部を選択してDLすると発生するようです。

検証として全てのファイルをDLしてみました。その場合は移動させて
戻してチェックをしてもフォルダ及び全てのファイルが100%でした。
そこから幾つかのファイルを抜き出し、抜き出したファイルを
DL対象から外しハッシュチェックをかけたところ、フォルダの%は減少し、
全てをDLした時には100%だったファイルまでもが減少していました。
そして、抜き出したファイルを元に戻しDL対象にしてチェックをしたところ、
フォルダ及び全てのファイルが100%になりました。

抜き出すファイルの数(容量?)によっては、フォルダは99.9%でも
抜き出さなかった個々のファイルは100%という事もありました。

個々のファイルの%が変動しても実際のファイルの容量は変化していません。

私としては一応の心配の種は取り除けたので解決となりましたが、
原因そのものは不明のままなので、もしわかる方がいましたら、
教えて頂けると幸いです。

て2さんChiさん、お騒がせ致しました。
暫くは覗きに来るので返信も出来ます。
この度は、ありがとうございました。
メンテ
ファイルの切れ目と ( No.7 )
日時: 2008/09/04 04:21
名前: Chi ID:16YGz6oQ

ファイルを選ぶとピースの完了状況が見れるようになっていると思う。
ファイルの切れ目とピースの切れ目は別、ピース単位でしかDLできない。

>原因が未だに謎なのですが、現象の仕組みは判りました。
プログラムの仕様ですね。これを避けるためには、
DLしないファイルもフルサイズでHD上に領域確保する必要が出てくるので
無駄が多い。DLする/しないが交互に並ぶと判りやすい。

>謎なファイルはThumbs.dbがありますが、DLの時点でDL対象から外しています。
>他には謎なファイルはありません。謎な名前のtxtはありますが、同じく
>DL対象から外しています。
こういう小さなファイルをDL対象外にしても、無意味。しかもプログラム上は
DLしていないので(存在していないので)、次のファイルの先頭のピースは
未完了となる仕様も当然かもしれない。

メンテ
まとめてお答えさせてもらいますね ( No.8 )
日時: 2008/09/04 05:20
名前: て2 ID:mdcO6Idk

※書いているうちにChiさんのありがたい書き込みがあったようで重なる部分がありますがご容赦下さい。m(__)m  訂正も面倒なのでw



Chiさんの仰られた境目の相違について、
例えばピースサイズが512kbとして、含まれるファイルのサイズがキッチリその倍数であるはずがなく、
ピース一個の中には、あるファイルの末尾データと開始データが両方含まれる形になるのが普通です。
ファイルの境目はピースの途中にある形になるので、境目に相違が生じると言う事です。
(作成側の設定で境界を一致させたトレントを作る事は出来ますが、容量の無駄が出来てしまうのでほとんど利用されていません)

この、境目が違う事により、一つのファイルBを保存しようとする時、次のC(あるいは前のA)ファイルの一部分は余分でいらないので
v1.01以前のバージョンではスパッと破棄される事になります。
しかし後にタスクを再開し、例えば破棄された部分を含むAorCをDLしようとする時、
“DLは基本的にピース単位で行われる”都合上、一部が破棄されてしまっているピースは丸ごとDLし直されることになると言う現象が起るのです。
もちろん、追加DLしなくても、状況によっては(一部オリジナルから変化した場合など)同じことが起るのは言うまでもありません。


Thumbs.dbですが、これもシステムファイルなので、有ったとしても隠しファイルを表示できる状態にしただけでは見ることは出来ません。
例えばこのファイルがタスクに含まれており、変更された場合、
ハッシュの照合でピース内容に食い違いが起きた時、DLし直しになるので、上記のような現象は同様に起りえます。

ちなみにこのファイルはサムネイルデータなので、フォルダの表示が「写真」「縮小版」の時、自動で生成(あるいは更新)されます。


知らぬ間にデータが置き換わる例で盲点なのが、
PNGやBMP等の上書きで劣化が起きない画像ファイルをプレビュー表示して、回転させた場合、
知らぬ間にファイルが更新される(画像に変化は無い)現象があります。お気をつけ下さい。


ところでタスクの再登録が失敗した事があったそうですが、
ファイルやフォルダの名前は問題ありませんでしたか?変更とか、特に文字化けの場合とか。
再登録にはディレクトリ構造も含め、微塵の狂いも無ければならないので。

名前といえば、ファイル名の末尾が.(ピリオド)や (空白)のように、本来付けれるはずの無い名前になっていると、ハッシュの照合がうまく行かず、結果再DLするはめになる場合も有ります。 本当に厄介な話ですが。

他に、Bitのファイル一覧で.bc!の拡張子が付いている物(つまりDL中は二重に付く)で、.bc!を外したまま照合にかけてしまった場合も再DLです(汗)


え〜、全体が99でも個別は全部100についてですが、
ひょっとしてファイル一覧の表示のまま切り替えずに確認したのでありませんでしたか?
基本的にファイル一覧の%進行状況は、一旦表示を切り替えないと更新されませんが・・



以上、まとめて疑問にお答えさせて頂きました。いかがでしょうか?
メンテ
原因(起因)はひょっとして? ( No.9 )
日時: 2008/09/10 02:09
名前: て2 ID:viZgtxBg

ねここさん、移動が起因ではなくタスクの再登録が起因ではと、強く思えます。

色々、状況が再現できないものか試してみようと試み始めた矢先、
一部選択タスクのデータをどのように移し変えて戻しても欠けファイルにはならなかったので、

「データを圧縮や移動」=バックアップ=タスクは既に削除されている(※つまりフォルダを元に戻すとはタスクの再登録?)
という事ではないかとようやく気付き、
実際に、(データには完璧絶対に一片の狂いも無いのに)状況を再現する事が出来ました。


恐らく間違いないと思います。
何故再登録だと、そうなるのか? という疑問が当然発生すると思いますが、これにもお答えしておきます。


先にお話したとおり、境界の差に起因して起る事は理解できてますね?
では、タスクの削除などはせずにハッシュの照合をすると100%を維持できるのはどうしてか?

答は.xmlファイルにあります。
torrentフォルダ内の、.torrentと同じ名前の.xmlファイルにどのデータが100%になっているのか、
ピースが一部破棄されても判断できるように情報が事細かにかきこまれているのです。(他にもどれを選択してるとかの情報等も)

しかしタスクを削除すると、当然.xmlファイルも不要になりますから同時に削除されてしまいます。
のちに、タスクを再開しようと再登録すると、どれが100%になっているかの判断はピースによるハッシュ照合しかありません。
.xmlが無い事で、非選択ファイルの上下にあるファイルの末尾(冒頭)部分が正しいのか正しくないのか判断しかねるわけです。

結果、今回のような現象が発生するといった流れです。


(ここまで熱弁しといて違ったら可也ハズカシイですけど… _ (。。)穴ハドコカナ? )

あ、対処法ですか?
えと、.xmlファイルも一緒に保存しておいてですね、
タスクを登録した後一度Bitを終了し、.xmlファイルを上書き(新たに登録された物と全く同じ名前になるように注意)して、
Bitを起動、目的のタスクをクリックなどして反転させると%表示が元通りになるはずです。
念のためハッシュの照合をして完全再開完了です。


今更ながら後学の為にも補足:
もちろんバージョン1.02以降なら、ピースの境界とファイルの境界の誤差余りは別途保存されるようになっているので問題なく選択DLできます。
又、すでに提案され、ねここさんもそうする様にしたと思われる<選り好みせずに全部DLする>のも一つの選択です。(この場合バージョンは何でも)

----------
9月10日2:08記事修正(補足追加)
メンテ

(全部表示中) もどる スレッド一覧 新規スレッド作成

題名 タイトルは次の画面で設定してください
名前  「名前#任意の文字列」でトリップ生成
E-Mail 入力すると メールを送信する からメールを受け取れます(アドレス非表示)
パスワード (記事メンテ時に使用)
投稿キー (投稿時 投稿キー を入力してください)
コメント

   クッキー保存