staroffice returning error message when write file to vfat partition only when using kernel 2.4.2. is it a known problem? is there a solution available?
On Thu, 26 Apr 2001, Flavio Arthur Leal Ferreira wrote:
staroffice returning error message when write file to vfat partition only when using kernel 2.4.2. is it a known problem? is there a solution available?
Yes, it is a known problem. I am not sure, if it has been fixed in 2.4.3. Here is the rather cryptic explanation from one our kernel people: [SNIP]
Staroffice uses truncate to expand the file, which doesn't seem to be allowed under vfat in 2.4.x.
probably. that's a bug in vfat then. I guess it's related to the fact fat doesn't support holes, but it should simply allocate the blocks, zero them out and make them dirty upon an extension trucate. That's the equivalent of cont_prepare_write, but cont_prepare_write only works for write after an lseek, I guess the same needs to be exported to truncate, it probably worth to keep the truncation stuff in buffer.c outside fat so other fs can share. [SNIP]
The same proplem arises with VMware, too, BTW. I hope, 2.4.3 has fixed this problem, but I cannot tell for sure right now. Bye, LenZ -- ------------------------------------------------------------------ Lenz Grimmer SuSE GmbH mailto:grimmer@suse.de Schanzaeckerstr. 10 http://www.suse.de/~grimmer/ 90443 Nuernberg, Germany Only the mediocre are always at their best.
* Lenz Grimmer [Fri, 27 Apr 2001 12:32:01 +0200 (CEST)]:
Here is the rather cryptic explanation from one our kernel people:
Well, I'll try to make it a bit less so ;-)
[SNIP]
Staroffice uses truncate to expand the file, which doesn't seem to be allowed under vfat in 2.4.x.
This means that Staroffice uses the truncate function from glibc (man 2 truncate), to expand a file (this is correct usage). This creates a file with a hole in it, extending from the end of the original file to the new file end: +-------------------------+ + + original file + + +-------------------------+ + ^new end <------- hole ----------> The problem is that the fat file system doesn't support files with holes. A solution would be if the fat driver would actually allocate the blocks needed to fill the hole, zero them out and write them to disk. But as of 2.4.2 that's not the case. Hope I could make it a bit more understandable :) -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
participants (3)
-
Flavio Arthur Leal Ferreira -
Lenz Grimmer -
Philipp Thomas