Re: fdatasync() error in shred from coreutils-5.2.1 on AIX 5.2

[Paul Eggert]

Following up on your message
<http://lists.gnu.org/archive/html/bug-coreutils/2004-05/msg00169.html>:

>> shred should try "lseek (fd, 0, SEEK_END)": did that fail too?
>
> The only lseek I see in the truss output is the following. It appears
> very early.
>   245772: open("/dev/lv00", 0400004001)                   = 3
>   245772: fstatx(3, 0x2FF21F98, 128, 010)                 = 0
>   245772: klseek(3, 0, 0, 0x00000002)                     = 0
>   245772: klseek(3, 0, 0, 0x00000000)                     = 0

Yes, I'd expect it to be early.  I don't know what klseek is, though;
if it returns zero, does that mean the file offset is zero?  If so,
AIX is saying the file size is zero.  In this case 'shred' assumes
that the OS isn't telling us the file size, so it goes ahead and
writes data until write error.

Is /dev/lv00 a block special device, or a character special device, or
something else?  POSIX says that seeks are supposed to work as one
would expect on regular files, block special files, and directories,
but seeks have implementation-defined behavior on other files.
However, I thought that AIX let you seek on character special files as
well (disk devices anyway).

Perhaps there's some other way to find the file size on AIX.
It's a bit odd that lseek isn't working though.