Adding files to queue from .sfv file
Moderator: Moderators
Adding files to queue from .sfv file
When downloading original releases in .rar, you could encounter problems like missing files in other peoples shares. How about if DC checked the sfv file and added the files missing to your queue?
This would in my opinion be quite usefull when downloading fresh releases and most people dont have the complete release yet. No more having to browse 20 people to find all the files for your queue.
Any comments on this?
xtc
This would in my opinion be quite usefull when downloading fresh releases and most people dont have the complete release yet. No more having to browse 20 people to find all the files for your queue.
Any comments on this?
xtc
-
- Posts: 506
- Joined: 2003-01-03 07:33
No, its a bad idea;
1) SFV-files usesa crc32-checksums and not tiger-tree-checksums-roots. In the future all shared files in the protocol will/should have such checksum before being shared.
2) SFV-files do not include size, another important part of a queue-entry: Since rar-files i no way have a unique size your feature-request is useless.
1) SFV-files usesa crc32-checksums and not tiger-tree-checksums-roots. In the future all shared files in the protocol will/should have such checksum before being shared.
2) SFV-files do not include size, another important part of a queue-entry: Since rar-files i no way have a unique size your feature-request is useless.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
the checksums doesnt matter in this case, we only need the filenames to add to know wich files we are missing, and if we find people who has the missing files in their share, DC could collect the TTH from them.
Filesize is a problem, but i think there could be a workaround. Since the file sets in a release always have the same size exept the last file. If the user we got the sfv file from has a couple of files from the release, and they are for instance 14,3MB big. Then we know that .rar/r00-47 would also be 14,3MB, and the last file that we dont know the filesize of, could just be downloaded from whatever source we find, and if CRC fails=delete and try another. Or maybe it could wait untill it finds two or more users with the same size of the last file before it puts it into queue.
A couple of minor flaws, but in theory it could work fine. You wont get any wrong files anyways because the CRC check disgards them.
Filesize is a problem, but i think there could be a workaround. Since the file sets in a release always have the same size exept the last file. If the user we got the sfv file from has a couple of files from the release, and they are for instance 14,3MB big. Then we know that .rar/r00-47 would also be 14,3MB, and the last file that we dont know the filesize of, could just be downloaded from whatever source we find, and if CRC fails=delete and try another. Or maybe it could wait untill it finds two or more users with the same size of the last file before it puts it into queue.
A couple of minor flaws, but in theory it could work fine. You wont get any wrong files anyways because the CRC check disgards them.
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- Posts: 18
- Joined: 2004-10-05 08:26
- Location: Want my ip? just ask!
Rar sharing is not flawed.
Rar sharing may be no more needable because of tth checksums if it comes to fileintegrity, but it allows to act dc as a fileswarming client.
And until there is no feature in dc that allows upload from the dctmp files together with multisourcedownload (what would allow together fileswarming in DC) Rar files will stay a method of sharing data in DC.
Though I hope with the possibilitys tth offers that fileswarming will be implemented in DC and make rar-file sharing a thing of the past.
Rar sharing may be no more needable because of tth checksums if it comes to fileintegrity, but it allows to act dc as a fileswarming client.
And until there is no feature in dc that allows upload from the dctmp files together with multisourcedownload (what would allow together fileswarming in DC) Rar files will stay a method of sharing data in DC.
Though I hope with the possibilitys tth offers that fileswarming will be implemented in DC and make rar-file sharing a thing of the past.
Imagination sets the spirit free,
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
-
- Forum Moderator
- Posts: 366
- Joined: 2004-03-06 02:46
-
- Posts: 18
- Joined: 2004-10-05 08:26
- Location: Want my ip? just ask!
-
- Posts: 18
- Joined: 2004-10-05 08:26
- Location: Want my ip? just ask!
Believe me with rar crc may not check every byte but ii is enought to enshure that you have the correct rar. Also does crc check enought to make shure the file wasn't corrupted.
Imagination sets the spirit free,
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
No, it isn't, and no, it doesn't.
-
- Posts: 18
- Joined: 2004-10-05 08:26
- Location: Want my ip? just ask!
Linked site is intresting but also shows that a unnoticed change by chance (normal data loss by ZA4 or sth else) is very impropabel. But it can more easily tricked than tth.cologic wrote:No, it isn't, and no, it doesn't.
So well for me that means it is well enough to get the corect rar, because rar sharing is done in reghubs where people are trustable or when done in open hubs the propability to get a freak that spoofs the file just for fun is low not zero but low.(Talked once to the programmer of ruri-ruri hubdestroyer, so yes such people exist.)
And ok each bit is checked, my mistake!
Imagination sets the spirit free,
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
Into distant lands of fantasy,
Close your eyes and you will see,
Within your mind there lies the key.
-
- Posts: 1
- Joined: 2003-11-27 19:27
Add to queue by sfv..... no, but how about csv?
Not so sure about adding to the queue from sfv files, but i'd certainly like to be able to add from csv files.
Any Chance?
I have seen a 'tweaked' version and the feature works quite well. It will even check against filelist in your dir and add users as sources if the file is found.
Any Chance?
I have seen a 'tweaked' version and the feature works quite well. It will even check against filelist in your dir and add users as sources if the file is found.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Add to queue by sfv..... no, but how about csv?
If there is a standard for including TTH, size, and filename in the CSV, then there's much more of a chance.[UK]Toecutter wrote:Not so sure about adding to the queue from sfv files, but i'd certainly like to be able to add from csv files.
Any Chance?
Adding from .CSV files seems to be a feature found in the one or two "image collector" (ahem) DC++ clients. It's of limited use to most users, as would anidb.net lookup, tvtome integration, etc.