Issue 97139 - Text document is always read-only from a nfs-mounted FAT partition
Summary: Text document is always read-only from a nfs-mounted FAT partition
Status: CLOSED DUPLICATE of issue 100123
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: current
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: mikhail.voytenko
QA Contact: issues@framework
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2008-12-11 12:42 UTC by mechtilde
Modified: 2009-08-31 13:20 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description mechtilde 2008-12-11 12:42:38 UTC
My system is Debian. There is also a server with a FAT32 partition.

I want to work on a document which is saved there.

I can open this document with OOo version 3.0.0 and work on it.

But if I want to do this with version OOO300_m13 or DEV3000_m37 I get a
read-only document.

For me it is a stopper for version 3.0.1 because of regression
Comment 1 michael.ruess 2008-12-11 13:40:16 UTC
Framework issue.
Comment 2 michael.ruess 2008-12-11 13:40:26 UTC
Framework issue.
Comment 3 thorsten.martens 2008-12-12 10:25:13 UTC
TM->JSK: As talked about, set you as owner
Comment 4 joerg.skottke 2008-12-12 10:54:48 UTC
The mount options are

/dev/sda7 on /mnt/export type vfat (rw,utf8,umask=007,gid=46)

- we can create a .~lock... file (so the filesys "rw")
- we do not delete the .~lock... file
- the filesys is automounted via fstab:
  UUID=B4F5-D411  /mnt/export     vfat    utf8,umask=007,gid=46 0       1

Was ok in 2.4 and 3.0

Reproduced this with Ubuntu Intrepid x86_64 with x86_64 StarOffice build.

ls -la says:

-rwxrwx---  1 root plugdev        0 2008-12-12 11:11 .~lock.x3-fabrikliste.ods#
-rwxrwx---  1 root plugdev        0 2008-12-12 11:10 test
-rwxrwx---  1 root plugdev    49186 2008-06-24 20:21 x3-fabrikliste.ods

the file "test" was crated using touch (for comparision/check of UMASK)
Comment 5 joerg.skottke 2008-12-12 10:57:25 UTC
Just for the records, maybe useful:

My local user id is:
uid=1000(skotti) gid=1000(skotti) Gruppen=4(adm),20(dialout),24(cdrom),
46(plugdev),108(lpadmin),123(admin),124(sambashare),1000(skotti)
Comment 6 mikhail.voytenko 2008-12-16 09:36:46 UTC
mav->mechtilde: I can not reproduce the problem with the network environment. It
either does not work for both OOO300_m9 ( OOo3.0 final ) and OOO300_m13 (
OOo3.0.1 branch ) if I mount the partition wrongly or work for both versions if
the mount done correctly. As I understood jsk he did not try OOo3.0 final, he
has mentioned that it works there because you have mentioned this.

Are you sure that your scenario does not work for OOO300_m13 but does work for
OOO300_m9? Are you testing the standard builds from OOo site? How exactly do you
mount the FAT network partition?
Comment 7 mechtilde 2008-12-16 09:57:59 UTC
I test it with OOO300_m9 final and OOO300_m13 on the same environment.

First I did my work with version OOO300_m13. as I ran into this problem I
started OOO300_m9 to finish my work without changing the partition mounting.

Details of my system I send per PM

Mechtilde
Comment 8 mikhail.voytenko 2008-12-16 10:19:58 UTC
mav->mechtilde: 
Ok, the scenario I have used was the samba connection to a Windows server with
FAT32 partition. So the scenario that jsk has used is closer to the original
one. I will investigate it.
Comment 9 mechtilde 2008-12-16 10:33:36 UTC
sorry I forget to inform you that it was mounted via nfs
Comment 10 mikhail.voytenko 2008-12-16 11:56:37 UTC
mav->mechtilde: No problem and thank you for quick answers.

By the way, in your email you have mentioned that .doc files were opened in the
scenario. The locking implementation for alien files has indeed been changed
between m9 and m13. Starting from m13 the alien files are also locked with OOo
lock file mechanics.

Could you please try whether there is the same problem while opening OOo
document ( .odt for example ) in OOO300_m9 from the problematic FAT partition.
Comment 11 mechtilde 2008-12-16 21:23:43 UTC
I do some tests to compare *.odt with *.doc

version 2.4.1 *.odt and *.doc are writable
version 3.0.0 *.odt read-only, *.doc writable
version OOO300_m13 *.odt and *.doc read-only
Comment 12 mikhail.voytenko 2008-12-17 13:53:50 UTC
mav->mechtilde: Thank you for checking this.

Could you please do one more test. Please open shell and try to create a new
file on the problematic location with touch command, something like "touch <path
to the nfs location>/ttt". Just to be sure that you have permissions to create a
new file on the location.
Comment 13 mechtilde 2008-12-17 14:04:30 UTC
yes I test it again I have the rights to write on the nfs partition

During the last tests I described above I did nothing change at the mount command.

I only change the started OOo version really nothing more.
Comment 14 mikhail.voytenko 2008-12-17 14:23:10 UTC
mav->mechtilde: Thanks a lot, one more test please ( actually I had to ask it
from the beginning ), could you please try to create a new file with the name
".~lock.file.ext#" on the location using touch command.
Comment 15 mikhail.voytenko 2008-12-18 17:18:28 UTC
It looks like I can reproduce the problem now.
The reason seems to be the combination of O_EXCL and O_CREAT that are used to
create the lock file. Such an nfs mount does not allow to open the file using
the mentioned combination of flags. These flags are necessary to avoid the race
condition on document opening, so that the creation of the lock file fails in
case there is already one.

By the way, I have the same problem if I use OOo2.x and try to create a new file
on the problematic partition, the old office can not create a new .odt document
there.

OOo3.1 will allow in this case to open the file without OOo locking if system
file locking is active. If system file locking is not active the user will be
notified that no locking is active.
Comment 16 mikhail.voytenko 2008-12-19 12:21:46 UTC
So I just want to summarize the results of investigation:

1) It is not a regression:
        - It never was possible to create a new file on the partition without
overwriting existing one, even OOo2.4 has a problem to create a new document on
this partition
        - the OOo file locking mechanics is specified for OOo3.0.x in the way,
that if it is not possible to create a lock file for a document in reliable way,
the document must be opened readonly
        - the fact that alien documents ( in this scenario MSOffice-format
documents ) were not locked in OOo3.0 was recognized as a bug, the fix for this
bug let the documents use OOo file locking mechanics, so the problem is now
reproducible for alien documents as well

2) The workaround ignoring file locking is not for OOo3.0.1:
        - to workaround the problem a new feature including UI changes is
necessary. It is already implemented in OOo3.1 cws mav43, the cws is already
nominated. A feature can not be integrated in OOo3.0.1.

Based on mentioned points above I would say that this is no showstopper and
would remove issue 93339 from the blocked issues.

Although we have the workaround, I would like to let the bug stay on OOo3.1
open. It could make sense to try to find a way to create a lock file reliably on
the system. Currently I still see no atomic replacement for O_EXCL | O_CREAT
combination in this scenario.
Comment 17 hennes.rohling 2008-12-19 14:47:41 UTC
Some time ago we had a similar problem with Solaris Sparc 64 where the NFS
client had a problem with files that were created with the flags O_CREAT +
O_EXCL. This is definietly was bug in the NFS implementation not with OOo.

Any workarounds will result in a non atomic behaviour, like creating the file
with O_CREAT, closing it and afterwards opening it with O_EXCL. So this bug has
to be fixed in the faulty NFS implementation.
Comment 18 mikhail.voytenko 2009-08-31 13:17:28 UTC
Since there is a possibility to turn the OOo file locking off in OOo3.2, there
is a workaround that would let the scenario work as it was before OOo3.0. I am
in doubt that there will be more efforts invested for this special scenario.
Setting to fixed.
Comment 19 mikhail.voytenko 2009-08-31 13:18:50 UTC
.
Comment 20 mikhail.voytenko 2009-08-31 13:20:03 UTC
Setting as duplicate to issue 100123, for which the possibility to turn the OOo
file locking was implemented.

*** This issue has been marked as a duplicate of 100123 ***
Comment 21 mikhail.voytenko 2009-08-31 13:20:29 UTC
.