bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21790: [PATCH] coreutils/cp: handle EOF extents correctly


From: Pádraig Brady
Subject: bug#21790: [PATCH] coreutils/cp: handle EOF extents correctly
Date: Fri, 30 Oct 2015 18:54:53 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 30/10/15 16:57, Pádraig Brady wrote:
> On 30/10/15 09:02, Dmitry Monakhov wrote:
>> fallocate can allocate extens beyond EOF via FALLOC_FL_KEEP_SIZE.
>> Currenly sparse engine tries to copy such extents which is wrong and
>> result in silent data corruption (leave file with incorrect size).
>>
>> ##TESTCASE
>> echo blabla > sparse_falloc.in
>> truncate -s 2M sparse_falloc.in
>> fallocate -n -o 4M -l 1M sparse_falloc.in
>> cp sparse_falloc.in sparse_falloc.out
>> cmp sparse_falloc.in sparse_falloc.out
> 
> Ouch.  Thanks for the analysis and patch.
> It looks correct.  I'll analyze further before applying.

This doesn't handle the --sparse==never case
(which is broken with and without the patch).

Also one might have an extent spanning the file size boundary,
in which this patch could miss the remaining data?

Also currently if the source file is being extended
while being copied, we continue to read, whereas we now wont.
Theoretically this is an issue when st_size doesn't match
what's available to be read, though maybe not a practical issue
since we don't use this path for a zero st_size, nor
sources that don't support fiemap anyway.

This might be an opportune time to rip out the fiemap stuff
in favor of SEEK{DATA,HOLE} anyway, which I intended to do
during this cycle.  For fix backporting sake though,
we should apply the minimal fix to the fiemap code first.

Attached is the current minimally tested patch.

thanks,
Pádraig.

Attachment: cp-trailing-extents.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]