Hi,
see
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=4%3A24.2.2~rc1-1&stamp=1709881487&raw=1:
/<<PKGBUILDDIR>>/sal/osl/unx/file.cxx: In function ‘void
osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’:
/<<PKGBUILDDIR>>/sal/osl/unx/file.cxx:71:26: error: narrowing conversion
of ‘4283649346’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
71 | #define CIFS_SUPER_MAGIC 0xFF534D42
| ^~~~~~~~~~
/<<PKGBUILDDIR>>/sal/osl/unx/file.cxx:795:14: note: in expansion of
macro ‘CIFS_SUPER_MAGIC’
795 | case CIFS_SUPER_MAGIC:
| ^~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/sal/osl/unx/file.cxx:72:26: error: narrowing conversion
of ‘4266872130’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
72 | #define SMB2_SUPER_MAGIC 0xFE534D42
| ^~~~~~~~~~
/<<PKGBUILDDIR>>/sal/osl/unx/file.cxx:796:14: note: in expansion of
macro ‘SMB2_SUPER_MAGIC’
796 | case SMB2_SUPER_MAGIC:
| ^~~~~~~~~~~~~~~~
make[2]: *** [/<<PKGBUILDDIR>>/solenv/gbuild/LinkTarget.mk:340:
/<<PKGBUILDDIR>>/workdir/CxxObject/sal/osl/unx/file.o] Error 1
This is due to
commit a8814b5921676b1c01a19b0af243712c55fb0307
Author: Kevin Ottens <kevin.ottens@xxxxxxxxxx>
Date: Fri Feb 2 15:39:36 2024 +0100
tdf#55004 Fix backup copy creation for files on mounted samba shares
There is an unfortunate interaction between file locking and backup
creation at save time.
openFilePath has logic to lock a file when opening. This goes through
fcntl to set a write lock on the file. Later on, when the user wants to
save changes, a backup copy might be created (very likely now since
this
is the defaults in the settings). To create this backup, the file is
opened again for reading. Unfortunately this open call fails due to the
lock (even though it is a write lock).
This commit changes the behavior. osl_file_adjustLockFlags now
checks if
the file is on a mounted samba share. If that's the case we force the
osl_File_OpenFlag_NoLock flag. No issue is then exhibited at backup
creation, allowing the save to proceed properly.
Change-Id: Ieab252f9f68598834e13339fc5fcea440f0a4c2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@xxxxxxxxxxxxx>
(cherry picked from commit 63efbc8ad8aae12b54e649c1495d1233c1a9b33f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163549
Can you have a look, please? I had a brief one, but that is a simple
define which shoudln't break. Then the switch does
switch (aFileStatFs.f_type) {
which uses
struct statfs aFileStatFs;
So it probably is a type difference in the kernel struct already for 32
vs 64 bit?
Regards,
Rene
