Discussion:
Regression trixi ->sid: sshfs on Olimex A20-Lime2
(too old to reply)
Arne Ploese
2024-04-18 10:20:01 UTC
Permalink
Hi Everyone,

I got some strage behaviour of sshfs.
Installing trixi fom the daily images an d installing sshfs and
mounting all works as expected.
But upgrading to sid breaks sshfs.
All mounted files and dirs are shown by "ls -l" have a size of 4096.
Larger files are truncated  if one attemts to read them.

Can anyone confirm this or has hints where to look for the error?

Arne
Arnd Bergmann
2024-04-19 08:50:01 UTC
Permalink
Post by Arne Ploese
Hi Everyone,
I got some strage behaviour of sshfs.
Installing trixi fom the daily images an d installing sshfs and
mounting all works as expected.
But upgrading to sid breaks sshfs.
All mounted files and dirs are shown by "ls -l" have a size of 4096.
Larger files are truncated if one attemts to read them.
Can anyone confirm this or has hints where to look for the error?
My guess would be that it's the 'stat' operation that is broken
by the time64 conversion. I don't see what happened exactly,
but I observe multiple possible issues:

- the fuse 'getattr' callback function takes a 'struct stat'
argument that has time_t information in it. If sshfs is built
with time64 while libfuse is still on time32 (or vice versa),
the ABI is mismatched and half the members in this struct get
the wrong data including the file size.

- The '.statfs' callback gets a 'struct statvfs' which has no
time data but has other file attributes that are different
when building with tiem64 because that now implies LFS, while
manually built versions of sshfs would previously get
the non-LFS struct layout.

- the time on the wire protocol is encoded as 'uint32_t', which
means it will overflow in the future. It appears to me that
this particular implementation only overflows in 2106 for the
unsigned times rather than 2038 would for a 32-bit (signed)
time_t.

Arnd

Loading...