-
Just wondering if you plan on wrapping the NNTP stuff.
2006-10-27 15:51:18 UTC in Visual Synapse
-
Assuming the sfv, nfo, etc are included in the recovery set then it is not possible to just ignore them. The way the math works is if you have 3 recovery volumes then you can recover up to three missing files that are included in the recovery set. So if you have 3 recovery volumes and 4 missing files you just cant ignore the extra missing file because that extra missing file is actually needed...
2005-10-20 08:15:05 UTC in parchive
-
Just realized that 0x0001100B is hexidecimal for 69643.. still looking for something to confirm my tables just in case I scewed the code up some how.
2005-10-19 08:53:29 UTC in parchive
-
sorry, tabs didn't transfer in the code.
2005-10-18 09:03:04 UTC in parchive
-
Just wanting clearification on what this means:
"The recovery data is generated using a 16-bit Galois Field (GF) with generator 0x0001100B"
When You say 16-bit I'm assuming GF(2^16)?
I found I had to convert a polynomial to binary (ie:
x^16 + x^12 + x^3 + x + 1 = binary: 10001000000001011B = decimal: 69643
this seems to work with this code:
prim_poly := 69643; //...
2005-10-18 08:57:44 UTC in parchive
-
Well, it all depends on how many PAR files you have (ofcourse by PAR files I mean the files in the PAR set, the extentions of these files would be like P00, P01, P02, etc).
If you have 3 PAR files you can restore 3 missing or bad parts. If you have 15, then you can restore 15. 40 = 40. 50 = 50.
etc.
2002-01-07 19:19:01 UTC in parchive
-
Well, it all depends on how many PAR files you have (ofcourse by PAR files I mean the files in the PAR set, they extentions of these files would be like P00, P01, P02, etc).
If you have 3 PAR files you can restore 3 missing or bad parts. If you have 15, then you can restore 15. 40 = 40. 50 = 50.
etc.
2002-01-07 19:18:34 UTC in parchive
-
Well, I did some snooping and I think I figured out what the problem may be... I haven't found a solution yet. The client I wrote has problems with that senario also.
I watched my code run through all the calculations that it used to invert the recovery matrix and I can not figure out how to calculate it for this case. Works great with everything else, its just this combination. Basicly...
2002-01-02 08:15:18 UTC in parchive
-
First off, yes, it does recreate the missing files perfectly. No there will not be any gaps, wrong bits, etc. The files generated are EXACTLY the same as the originals (except maybe the file date/time and flags).
I felt much the same when I first found out about PAR... How the hell does it do it? Well, unless you like math *A LOT* i suggest just taking it on faith. Otherwise I'd say...
2002-01-02 07:52:46 UTC in parchive
-
Sorry, I forgot to add that I also think the current PAR spec could be used for floppy disk recovery if the original archives were just a bit smaller which would allow the par files to also be small enough to fit on a diskette.
2001-12-28 21:48:33 UTC in parchive
