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.«
