Fix an integer overflow when computing the size of a deleted entry

This bug prevented SnapRAID to read a valid content file, in case
a deleted entry bigger than 4 GB was present.
This could be reproduced deleting a file bigger than 4 GB and then sync.

HISTORY

@@ -3,6 +3,15 @@ SnapRAID HISTORY
 
 9.1 2015/11
 ===========
+ * Fixes a bug when reading a content file with a deleted entry
+   bigger than 4 GB. This was a regression introduced in
+   version 9.0 that could result in the impossibility to read
+   a valid content file, after a deletion of a file bigger than 4 GB
+   in the array.
+   If this happened to you, just upgrading to 9.1 fixes the issue,
+   and it allows you to continue to work.
+   Note that this bug only prevented to run 9.0, but your data was still
+   protected and could have been recovered using the versions 8.1 or 9.1.
  * In Winwdows disables the file zero check requring the --force-zero
    option. This check is intended for possible case using ext3/4 in Linux,
    and there is no evidence that in Windows it's possible at all.

cmdline/state.c

@@ -2012,7 +2012,7 @@ static void state_read_content(struct snapraid_state* state, const char* path, S
 					/* if it's a run of deleted blocks */
 
 					/* allocate a fake deleted file */
-					deleted = file_alloc(state->block_size, "<deleted>", v_count * state->block_size, 0, 0, 0, 0);
+					deleted = file_alloc(state->block_size, "<deleted>", v_count * (data_off_t)state->block_size, 0, 0, 0, 0);
 
 					/* mark the file as deleted */
 					file_flag_set(deleted, FILE_IS_DELETED);