• Regression trixi ->sid: sshfs on Olimex A20-Lime2

    From Arne Ploese@21:1/5 to All on Thu Apr 18 12:20:01 2024
    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

    <html><head><style>pre,code,address {
    margin: 0px;
    }
    h1,h2,h3,h4,h5,h6 {
    margin-top: 0.2em;
    margin-bottom: 0.2em;
    }
    ol,ul {
    margin-top: 0em;
    margin-bottom: 0em;
    }
    blockquote {
    margin-top: 0em;
    margin-bottom: 0em;
    }
    </style></head><body><div>Hi Everyone,</div><div><br></div><div>I got some strage behaviour of sshfs.</div><div>Installing trixi fom the daily images an d installing sshfs and mounting all works as expected.</div><div>But upgrading to sid breaks sshfs.</
    <div>All mounted files and dirs are shown by "ls -l" have a size of 4096. Larger files are truncated &nbsp;if one attemts to read them.</div><div><br></div><div>Can anyone confirm this or has hints where to look for the error?</div><div><br></div><
    Arne</div><div><span></span></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arnd Bergmann@21:1/5 to Arne Ploese on Fri Apr 19 10:50:01 2024
    On Thu, Apr 18, 2024, at 12:17, Arne Ploese wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)