Is this behaviour mandated in a standard, or is it just different from
previous behaviour? I'm not saying it _isn't_ a bug, but I don't see
how seeking past the end of a block device is very useful.
> Attempting to seek through file /dev/hda3
>
> lseek(6 Gb ): errno = 0 ret = 6442450944
> lseek(7 Gb ): errno = 0 ret = 7516192768
> lseek(8 Gb ): errno = 0 ret = 8589934592
> lseek(9 Gb ): errno = 0 ret = 9663676416
>
>
> Sample output on the same machine, but booted with kernel 2.4.18:
>
> Attempting to seek through file /dev/hda3
>
> lseek(6 Gb ): errno = 0 ret = 6442450944
> lseek(7 Gb ): errno = 0 ret = 7516192768
> lseek(8 Gb ): errno = 22 ret = -1
> lseek(9 Gb ): errno = 22 ret = -1
>
> [6] Reason for reporting this problem
> ---------------------------------------------------
> Our multi-platform backup product relies on proper behaviour of the
> lseek() command to calculate a rawdisk size.
Well, e2fsprogs has a similar test that it uses if the BLKGETSZ ioctl
fails, but I don't see how this new behaviour is a real problem. All you
have to do is check if _either_ lseek(offset) fails or read() from that
offset fails to know you are past the end of the block device. It hardly
changes the algorithm at all.
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/