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

[Albert Chin]

On Sat, May 15, 2004 at 11:13:08PM -0700, Paul Eggert wrote:
> Albert Chin <address@hidden> writes:
> 
> > According to the man page ...
> >   The fsync subroutine is unsuccessful if one or more of the following
> >   are true:
> >   ...
> >   EINVAL The file is not a regular file.
> 
> Thanks for reporting that.  I looked through "shred" and found some
> related problems too, while I was at it.  Here's a proposed patch,
> relative to CVS coreutils.

Ok, I copied src/shred.c from CVS and a few other files to make it
build against 5.2.1. I no longer get a fdatasync()/fsync() error but:
  $ df -Ik /test
  Filesystem    1024-blocks      Used      Free %Used Mounted on
  ...
  /dev/lv00           65536      2100     63436    4% /test

  $ /tmp/gshred -v /tmp/lv00
  /tmp/gshred: /dev/lv00: pass 1/25 (random)...
  /tmp/gshred: /dev/lv00: pass 1/25 (random)...31MiB
  /tmp/gshred: /dev/lv00: pass 1/25 (random)...71MiB
  /tmp/gshred: /dev/lv00: pass 1/25 (random)...613MiB

Rather odd that we're at 613 when the logical volume is 64MiB.
According to dopass():
 * If *sizep == -1, the size is unknown, and it will be filled in as soon
 * as writing fails.

So, does this mean writing isn't failing (I've confirmed *sizep == -1)?
Pulling the latest src/shred.c into 5.2.1 is somewhat questionable but
this still seems odd.

/test is an AIX JFS file system.

-- 
albert chin (address@hidden)