[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] doesn't add up
From: |
Jason Baker |
Subject: |
Re: [Mldonkey-users] doesn't add up |
Date: |
15 May 2004 20:55:54 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) |
Jason Baker <address@hidden> writes:
> Jason Baker <address@hidden> writes:
>
> ... [contradictory upload accounting]
>
> OK. If I restart mlnet, upload accounting makes sense, except that I
> get all kinds of requests for complete files in incoming, and shared
> files of my own that never get services, and my upload queue remains
> empty.
> > Message from client[741] xDonkey abuser(eDonkey) [192.168.0.11:13460]
> > QUERY FILE OF 20A11F6EC3516CCF49CEF59EB3869C48
> > Sent to client[741] xDonkey abuser(eDonkey) [192.168.0.11:13460] on
> > localtime: 1
> > 4/ 5, 07:45:07
> > QUERY FILE REPLY OF 20A11F6EC3516CCF49CEF59EB3869C48
> > name = "Negativland:The Letter U And The Numeral 2 - Dead Dog Records.zip"
> ...
> > Message from client[741] xDonkey abuser(eDonkey) [192.168.0.11:13460]
> > QUERY CHUNKS OF 20A11F6EC3516CCF49CEF59EB3869C48
> > Sent to client[741] xDonkey abuser(eDonkey) [192.168.0.11:13460] on
> > localtime: 1
> > 4/ 5, 07:45:07
> > CHUNKS for 20A11F6EC3516CCF49CEF59EB3869C48
> > 000000000
>
> It looks like mlnet thinks all my complete files are actually empty:
> Does anyone know what might cause this? I noticed done_files in
> files.ini is empty, but should there even be entries for files that
> originate locally?
diffs against latest release enclosed.
Jason
------------------------------------------------------------------------
diff -ur ../mldonkey-2.5.21-orig/src/daemon/common/commonSwarming.ml
./src/daemon/common/commonSwarming.ml
--- ../mldonkey-2.5.21-orig/src/daemon/common/commonSwarming.ml Wed May 5
15:56:46 2004
+++ ./src/daemon/common/commonSwarming.ml Sat May 15 18:48:11 2004
@@ -513,8 +513,10 @@
if t.t_verified_bitmap.[i] < '2' then begin
t.t_verified_bitmap.[i] <- '2';
t.t_ncomplete_blocks <- t.t_ncomplete_blocks + 1;
- if immediatly then verify_block t i
- end
+ lprintf "making %d verifiable\n" i;
+ end;
+ if immediatly then verify_block t i
+
(*************************************************************************)
(* *)
diff -ur ../mldonkey-2.5.21-orig/src/networks/donkey/donkeyShare.ml
./src/networks/donkey/donkeyShare.ml
--- ../mldonkey-2.5.21-orig/src/networks/donkey/donkeyShare.ml Wed May 5
15:56:48 2004
+++ ./src/networks/donkey/donkeyShare.ml Sat May 15 18:49:42 2004
@@ -20,6 +20,7 @@
open CommonGlobals
open Printf2
open Md4
+open CommonDownloads
open CommonFile
open CommonShared
open CommonTypes
@@ -95,6 +96,32 @@
(* file.file_chunks <- Array.make file.file_nchunks PresentVerified; *)
(* file.file_absent_chunks <- []; *)
(* file.file_all_chunks <- String.make file.file_nchunks '1'; *)
+ (* Should we trust mtimes, or reverify each file. If we trust
+ * mtimes, I guess we have to call
+ * Int64Swarmer.set_verified_bitmap "333..."
+ * this seems unspeakably ugly, but the alternative is to reverify
+ * every shared file every hour.
+ *
+ * If, however, we could somehow avoid regenerating shared files
+ * when the directory is scanned, verifying everything on startup
+ * might be acceptable.
+ *
+ * Also, timestamps would be more resilient if we took the maximum
+ * of mtime and ctime. (Touch will set ctime to the current time
+ * regardless of the mtime being set.)
+ *)
+ match file.file_swarmer with
+ Some s -> (let len = Array.length file.file_md4s in
+ let ver_str = String.make len '3' in
+ Int64Swarmer.set_verified_bitmap s ver_str;
+ (*
+ Int64Swarmer.set_present s [(Int64.zero, file_size file)];
+ (* If we don't verify now, it will never happen! *)
+ Int64Swarmer.verify_all_blocks s true;
+ *)
+ lprintf "verified map of %s = %s\n"
+ codedname (Int64Swarmer.verified_bitmap s))
+ | None -> lprintf "no swarmer for %s\n" codedname;
(try
file.file_format <- CommonMultimedia.get_info
(file_disk_name file)