Persistent download history
Moderator: Moderators
Persistent download history
Hi all!
I want to implement a download history which is stored on disk for future use. I do not want to download some files twice. So files will be red in download queue when you add a duplicate.
So the question is the following. Is it enough to store only TTH root value to identify file? Or may be I need to store TTH + file size? As I understand two or more files can have a the same TTH root value.
Thanx.
I want to implement a download history which is stored on disk for future use. I do not want to download some files twice. So files will be red in download queue when you add a duplicate.
So the question is the following. Is it enough to store only TTH root value to identify file? Or may be I need to store TTH + file size? As I understand two or more files can have a the same TTH root value.
Thanx.
Re: Persistent download history
Yes.Sunnyboy wrote:Is it enough to store only TTH root value to identify file?
No. Store "abc" in filea.txt and "def" in fileb.txt. They will have the same size but NOT the same TTH. With TTH, the name and file size is disregarded.Sunnyboy wrote:Or may be I need to store TTH + file size? As I understand two or more files can have a the same TTH root value.
Re: Persistent download history
Thanx ullner.ullner wrote:No. Store "abc" in filea.txt and "def" in fileb.txt. They will have the same size but NOT the same TTH. With TTH, the name and file size is disregarded.
But can be the situation when two files with different size have the same TTH? If yes, I think it will be more effective to store TTH + file size to identify files in future. May be it is redundant. I'm not sure.
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
Re: Persistent download history
What I am aware of have no TTH collisions been detected so far and if a collision would occur. I would say that it did would it be time to find a new hashing technique to use.Sunnyboy wrote:Thanx ullner.ullner wrote:No. Store "abc" in filea.txt and "def" in fileb.txt. They will have the same size but NOT the same TTH. With TTH, the name and file size is disregarded.
But can be the situation when two files with different size have the same TTH? If yes, I think it will be more effective to store TTH + file size to identify files in future. May be it is redundant. I'm not sure.
Sunnyboy wrote:DC++ logs filename, size, speed etc., but not TTH. So it is not a solution
Press F1 in DC++ to get further information on how to use DC++ more efficently.DC++ Helpfile wrote:Download and Upload Log Format
%[user] - User name
%[userip] - User's IP address
%[hub] - Hub name
%[hubip] - Hub's IP address
%[size] - File Size
%[sizeshort] - File size, shortened and including units
%[chunksize] - Size uploaded this session
%[chunksizeshort] - Size uploaded this session, short and including units
%[actualsize] - Actual uploaded bytes, affected by compression
%[actualsizeshort] - Actual uploaded bytes, short and including units
%[speed] - Speed of the transfer
%[time] - Elapsed time of the transfer
%[sfv] - Whether the file was checked against a SFV file (0 = no, 1 = yes).
%[tth] - Base32 representation of the tiger tree root hash
Only for Download log: %[target] - Local path and filename
Only for Upload log: %[source] - Local path for the upload.
Default download log format: %Y-%m-%d %H:%M: %[target] downloaded from %[user], %[size] (%[chunksize]), %[speed], %[time]
Default upload log format: %Y-%m-%d %H:%M: %[source] uploaded to %[user], %[size] (%[chunksize]), %[speed], %[time]
For the last year (since some 0.67x version, I guess),
has existed in UploadManager.cpp. I haven't tested it to work, nor have I ever intentionally used it, but support code does exist.
Code: Select all
if(u->getTTH() != NULL) {
params["tth"] = u->getTTH()->toBase32();
}
Thanx for all.
I already wrote a class(singleton) History which listens events from DownloadManager and writes TTH of all completed files in hash_set. Then in QueueManager I check new items, and if their TTH already exist in History, I mark them with special flag. This flag is checked in queue list to determine color of item.
So the original question was - Can I rely on TTH? Do I have to log not only TTH, but may be size of file or some additional checksum to reduce the risk of mistake? I know that TTH can lead to collision. What is the best set of information do I have to log?
Thanx.
I already wrote a class(singleton) History which listens events from DownloadManager and writes TTH of all completed files in hash_set. Then in QueueManager I check new items, and if their TTH already exist in History, I mark them with special flag. This flag is checked in queue list to determine color of item.
So the original question was - Can I rely on TTH? Do I have to log not only TTH, but may be size of file or some additional checksum to reduce the risk of mistake? I know that TTH can lead to collision. What is the best set of information do I have to log?
Thanx.
Yes, you can rely on TTH. There is no use of you using the file type to ensure file indentity.Sunnyboy wrote:So the original question was - Can I rely on TTH? Do I have to log not only TTH, but may be size of file or some additional checksum to reduce the risk of mistake?
Well, it could but there have been no records of a collision concerning TTH.Sunnyboy wrote:I know that TTH can lead to collision.
Yes, you could use %[tth]. Though, when a upload is complete (or begin, I don't remember which), no TTH flag is set so you don't get the TTH of the upload. This is what I meant by 'no code support'. Aswell, if I remember correctly, DC++ throws an exception from the above code because there's no TTH to convert to base32.cologic wrote:For the last year (since some 0.67x version, I guess),has existed in UploadManager.cpp. I haven't tested it to work, nor have I ever intentionally used it, but support code does exist.Code: Select all
if(u->getTTH() != NULL) { params["tth"] = u->getTTH()->toBase32(); }