[Mldonkey-users] File corruption following, mldonkey hardening proposal

[Lionel Bouton]

Hi,

2.4-1 just commited some files that were corrupted according to ed2k_hash...

I would like to see a "check_hashes_at_commit 0/1" option that would 
recheck all chunks before commiting and throw invalid ones for the 
following reasons :

- bug exists and for people using literraly tens of different cvs 
versions for downloading a single file, ensuring at the end that not a 
single version had a bug that could corrupt a chunk is rather difficult.
- chunk deduplication might/do pose rather tricky problems (see below).
- mldonkey can't know whatever happened to a chunk after it was checked 
(think about a fs recovery, ...)
- I believe it should be an option (it adds an overhead at commit time 
that won't be welcomed by everybody).

About the chunk dedup :

I've seen mldonkey-2.4-1 create "empty" files in the commut directory. 
That is, a file that was present in this directory, but renamed, moved 
or deleted (usually a short time after commit).
Most of the time it is a 0-length file, but I've seen files full of zero 
with the original file size too (using ext3, so they were sparse file).

When deduplicating chunks, I believe that mldonkey doesn't check the 
actual chunk but its cache (pre-calculated md4s of shared files' chunks).
The problem is that if the chunk is now full of zeros due to the 
behavior described above (or whatever bogus content for that matter), 
the deduplication process just push invalid chunks to the poor 
destination file :-(

So I'd advise to do the dedup like this :
1/ copy the whole chunk recomputing the hash at the same time (exception 
handling for the open() error case, but probably already done),
2/ check the hash ->
2a/ ok : mark the chunk complete
2b/ ko : update the cache for the whole source file from which the chunk 
came, don't mark the chunk complete.

I just checked the dedup messages in my mldonkey's log and found out the 
following :

Sorry for the length, but it emphasizes the problem's impact here !

Files 1266 1258 1259 1260 1243 1244 1246 1247 1251 1235 1237 1239 1240 
1242 821 822 823 824
825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 
843 845 846 847 848
849 850 851 852 853 854 855 868 869 870 871 872 873 874 875 876 877 878 
879 880 881 882 883
884 885 886 887 888 889 890 891 892 893 899 900 901 902 903 904 905 906 
907 908 909 910 911
912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 
930 931 932 933 934
935 936 938 939 940 941 942 945 946 947 948 949 950 951 952 953 954 955 
956 957 959 960 961
962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 
980 981 982 983 984
985 986 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 
1003 1004 1005 1006 1
007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 
1021 1022 1023 1024 102
5 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 
1040 1041 1042 1043
1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 
1058 1060 1062 1063 10
64 1065 1066 1067 1068 1070 1071 1072 1073 1074 1075 1076 1077 1079 1080 
1083 1089 1090 1091
1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 
1107 1108 1109 1110 1
111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 
1126 1127 1128 1129 113
0 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 
1145 1146 1147 1148
1153 1154 1155 1156 1157 1160 1161 1162 1163 1164 1166 1167 1168 1169 
1170 1171 1173 1175 11
76 1178 1179 1180 1182 1183 987 1187 1188 1189 1190 1191 1192 1193 1194 
1195 1196 1197 1198
1199 1201 1202 1203 1206 1208 1209 1210 1211 1212 1213 1218 1219 1220 
1221 1222 1223 1224 12
25 1226 1227 1229 share block D7DEF262A127CD79096A108E7A9FC138

From a quick look, this is the only chunk md4 that is shared by more 
than 2 files, guess what the md4 for a chunk full of zeros is ?

Needless to say, I must do an ed2k_hash for every completed download, 
force a new download and hope that the corrupted file I rename as 
"filename_(corrupt).ext" won't generate a new heap of zero chunks

Hope it helps,

LB.