Bug 90418 (cifs_fread_err) - Wrong number of bytes when reading file opened in libreoffice calc on cifs
Summary: Wrong number of bytes when reading file opened in libreoffice calc on cifs
Status: RESOLVED INVALID
Alias: cifs_fread_err
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-02 18:40 UTC by jds
Modified: 2015-10-18 10:37 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Short source code to reproduce error (1.10 KB, application/gzip)
2015-04-02 18:40 UTC, jds
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jds 2015-04-02 18:40:10 UTC
Created attachment 114566 [details]
Short source code to reproduce error

When reading a CSV file from cifs mounted path which is already open with full read/write permission in libreoffice, fread (in C) returns an incorrect file size for the CSV file when reading 2**17 or more bytes at a time. If the file is opened in read-only mode, the correct file size is returned. Share is mounted through fstab, and the error still occurs mounting with pamount or mount.

The problem does appear to be with libreoffice and not cifs/gvfs as fread returns the correct file size when any another application has the file open in either read-only or read-write mode, e.g. a text editor. Likewise, when reading less than 2**17 bytes at a time, the correct file size is also returned whether or not the file is opened in read-only mode.

Many libraries are built using fread, and so returning the wrong file size will likely cause segfaults. This bug first manifested for me using python/pandas.

Short sample code attached to reproduce problem. In order to test, place CSV file on a cifs or gvfs share, open with libreoffice, then run the script, pointing it to the same file. It will report the file size as 131072 bytes, whereas it is actually 131 bytes. If you recompile the test code with a chunk size < 2**17, it works fine, or if you run it with libreoffice opening the file in read-only mode.
Comment 1 Christian Lohmaier 2015-04-10 13:17:53 UTC
4.2.7 is very old, and already End-of-life.

So please check if the same effect still occurs with a current version such as 4.4.2 or one of the daily/master builds.

Besides: where's the actual problem/use-case that is affected by this?
I mean you open in read/write, so any application that opens at the same time should expect that the file can change midway. As you wrote yourself: when you open in read-only mode, then LO doesn't cause interference...
Comment 2 QA Administrators 2015-10-14 19:50:58 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

This NEEDINFO message was generated on: 2015-10-14
Comment 3 Julien Nabet 2015-10-18 10:37:09 UTC
No feedback since 6 months, let's put this one to INVALID.

jds: if you still reproduce this with recent LO version (last stable one is 5.0.2), don't hesitate to reopen this tracker. In this case, please provide information indicated by Christian.