Handling of 32/64 bit off_t by getdents64()

[Nikolaus Rath <Nikolaus@rath.org>]

Hello,

For filesystems like ext4, the d_off values returned by getdents64()
seem to depend on the kind of process that issues the syscall.

For example, if I compile test program with -m32 I get:

$ ./readdir32 
--------------- nread=616 ---------------
inode#    file type  d_reclen  d_off   d_name
32253478  ???          40  770981411  test_readlog.py
32260181  ???          24  776189020  ..
[...]

If I compile for 64 bit, I get:

$ ./readdir64 
--------------- nread=616 ---------------
inode#    file type  d_reclen  d_off   d_name
32253478  ???          40 3311339950278905338  test_readlog.py
32260181  ???          24 3333706456980390508  ..
[...]

This is despite d_off being declared as ino64_t in the linux_dirent64
struct.


This is presumably intentional, because (again as far as I can tell), if
getdents64 returns a full 64 bit value for a 32 bit system, libc's
readdir() will return an error because it cannot fit the value into
struct dirent.


As far as I know, there is no way for a FUSE filesystem to tell if the
client process is 64 bit or 32 bit. So effectively, a FUSE filesystem is
limited to using only the lower 32 bits for readdir offsets. Is that
correct?

This would be quite annoying because it means that passthrough
filesystems cannot re-use the underlying filesystems d_off values
(since they will be full 64 bit for a 64 bit FUSE process).


Is there a way for a 64 bit process (in this case the FUSE daemon) to
ask for 32 bit d_off values from getdents64()?


Would it be feasible to extend the FUSE protocol to include information
about the available bits in d_off?


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«