linux-ext4 - Re: [PATCH 2/2 v2] debugfs: dump a sparse file as a new sparse file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	9 Jan 2013 19:42:32 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	linux-ext4@...r.kernel.org, linux@...izon.com, tytso@....edu,
	wenqing.lz@...bao.com
Subject: Re: [PATCH 2/2 v2] debugfs: dump a sparse file as a new sparse file

> 2) If the sparse flag is set, then ext2_file_read() will stop the read
> when it runs into the first uninitialized or sparse block.  That is,
> consider the example file which has 8k of data, a 4k uninitialized
> block, and then 12k of data after that.  If the sparse flag is passed
> to ext2_file_open(), then ext2fs_file_read(fd, buf, 16384, &got) will
> read 8k of data into buf, and return with got set to 8192.
> 
> 3) To distinguish between EOF and a sparse block, if the current file
> offset is pointed at a sparse/uninitialized block, and the sparse flag
> was passed to ext2_file_open(), then in addition to *got getting set
> 0, ext2_file_read() will also return a new error code,
> EXT2_ET_READ_HOLE_FOUND.

Given that the current model of ext2fs_file_read is that it returns
some valid data in *got, AND the reason it stopped short as the retval,
wouldn't it make more sense to return EXT2_ET_READ_HOLE_FOUND from the
*first* read call?

It's a minor thing, as you just end up falling back to the Unix syscall
model of deferring the error until the next read call, but wouldn't
it be more consistent?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html