Re: is -1 really too "large" ?

On Mon, Oct 21, 2013 at 08:40:20PM +0200, Toralf Förster wrote:
 > got today :
 > 
 >  run trinity at Mon Oct 21 20:38:27 CEST 2013 28#-1 M=/mnt/nfsv4
 > 
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000004924000000cb': Device or resource busy
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000003fdd000000a9': Device or resource busy
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs00000000000034230000007a': Device or resource busy
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000002d320000006b': Device or resource busy
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000001a7c00000035': Device or resource busy
 > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs00000000000017600000002a': Device or resource busy
 > Trinity v1.3pre  Dave Jones <[email protected]>
 > Done parsing arguments.
 > Marking all syscalls as enabled.
 > [init] Enabled 351 syscalls. Disabled 0 syscalls.
 > [init] Using pid_max = 32768
 > [init] Started watchdog process, PID is 15311
 > [main] Main thread is alive.
 > [main] Generating file descriptors
 > [main] Something went wrong during nftw(/mnt/nfsv4/victims/v1/v2). (-1:Value too large for defined data type)

So NFS returned -EOVERFLOW. Not sure why it would do that, but I'm goingto guess it
came from nftw internally doing an lseek.  lseek's man page suggests..

       EOVERFLOW
              The resulting file offset cannot be represented in an off_t.

64bit server and 32 bit client perhaps ?

	Dave