On Wed, 3 Nov 1999, Pavel Pisa wrote:
> Hello all,
> I have two things on my desk now.
>
> -----------------------------------------------------------------------
> 1) There is bug in FAT FS which is triggered by lseek after end of file
> and then calling write. Old code allocated and zeroed all necessary
> clusters to write at wanted position. New code cannot do that. I use
> this for allocating new STACKER CVF file by program MKSTACFS.
>
> To trig bug call something like "mkstacfs stacvol.000 10000 4"
> on any mounted DOS partition. It should create 5MB long file
> "stacvol.000", but it leads to :
Look at fat_write_partial_page(). I've deliberately disabled get_block()
behind the end of file. The problem being: you need to allocate new blocks
in between, right? You also need to write zeroes there. You _can't_ use
buffer cache here - this stuff will go into the page cache and the last
thing you want is a bunch of dirty buffer_heads in buffer cache,
conflicting with the per-page buffer_heads that will be created by normall
accesses. You have to allocate pages in page cache, fill them with zeroes
and only then write to disk. It can't be done from ->get_block() - you'll
deadlock immediately. Solution: put that into ->writepage() - it can do
the right thing. And fat_write_partial_page() does. Please, check it and
check block_write_cont_page() (in fs/buffer.c).
AFAIK breakage in 2.3.24 was due to the fact that page allocation had been
changed (functions work with stuct page * instead of the address of page's
body) and code in fs/fat/file.c was not updated (compiler was quite happy
since there used to be an explicit typecast - originally we had (unsigned
long)page and it suppressed warnings; the right thing was page_address(page))
2.3.25 should be OK with that - this breakage had been fixed (it was there
for a couple of releases around 2.3.24).
> I did not try to fix this. I can write simple code to allocate
> full needed cluster chain, but I do not know reasons of original
> writer. There is no comment for "i_realsize". It seems, that it is
> file size rounded up to multiple of SECTOR_SIZE.
Nope. It's the amount of actually initialized data in file.
> I think, that multiple of cluster size would have more sense,
> but I realy do not know reasons of original writer.
Check the aforementioned functions.
