On 05.06.2012 11:39, Jean-Pierre André wrote:
> Hi,
>
> Bogdan wrote:
>> W dniu 04.06.2012 22:04, Jean-Pierre André wrote:
>>
>>> Hi,
>>>
>>> Bogdan wrote:
>>>
>>>> Hello everybody.
>>>>
>>>> I've prepared a small patch for utils.c and ntfswipe.c:
>>>> - in utils.c, checking for allocated blocks is fixed to pre-fetch
>>>> data on the first run,
>>>>
>>>>
>>> - if ((lcn< bmplcn)
>>> + if ((bmplcn< 0) || (lcn< bmplcn)
>>> || (lcn>= (long long)(bmplcn + (sizeof(buffer)<< 3)))) {
>>>
>>> Can you explain this one ?
>>>
>>> AFAIK lcn is always>= 0 there, and bmplcn can only be
>>> negative when it is == -(sizeof(buffer)<< 3), so the last
>>> condition is true when bmplcn is negative.
>>> So the change does nothing.
>>>
>> There are 2 issues here. The clue issue is the "(bmplcn< 0)"
>> condition, which makes us fill the buffer on the first run.
>>
>
> Which the third condition is expected to do.
>
>> The second issue is the second condition (the one you're talking
>> about). Yes, "-(sizeof(buffer)<< 3)" makes bmplcn negative, so it
>> looks like this condition will always be the same as "lcn => 0". But
>>
>
> I see no relation between the two conditions.
>
>> there is one small detail that makes the change: bmplcn is STATIC. It
>> holds its value between calls. The second condition checks if "lcn"
>> doesn't fall beyond the current buffer.
>>
>
> Maybe youPlease exhibit a circumstance where the original condition
> and the new one lead to different behavior.
I guess it won't happen during normal work. On the first run, which I
was interested in, we effectively check for "(lcn < bmplcn) || (lcn >=
0)". So, an error that would cause this block to be skipped could
happen only if "lnc >= bmplcn && lcn < 0", but the logical cluster
number won't be negative (during normal work).
OK, I see now. I can remove this change from my patch. This isn't
very clear, though.
>>>> Additionally, a small correction is added to the layout.h file
>>>> (change from floating-point constant to long long), so that there
>>>> are no warnings when ntfsck.c is being compiled. You can make this
>>>> conditional, there are autoconf tests that check for support of the
>>>> "long long" type in the C compiler.
>>>>
>>>>
>>> Hmm, this patch is wrong :
>>>
>>> -#define magicNTFS const_cpu_to_le64(0x202020205346544e) /*
>>> "NTFS " */
>>> +#define magicNTFS const_cpu_to_le64(0x202020205346544ll) /*
>>> "NTFS " */
>>>
>> Why do you think it's wrong? I change a floating point value to a
>> long long.
>>
>
> The final 'e' is not a floating-point indication, but a part
> of the encoding of the character 'N'. So you changed the
> value, without making it more portable.
Right. Will be corrected in the patch I'll send in the second mail.
Strange that GCC was saying something about floating point, which
mislead me.
--
Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
