Alexander Viro writes:
[about file expansion by truncate]
> Basically, the program depends on behaviour that was never guaranteed
> to be there.
1. it is useful
2. it is documented in a few places AFAIK
3. it is portable enough for Star Office (Solaris I guess)
> BTW, _some_ subset is doable o
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> IOW, if it's worth doing at all it probably should be
> on expanding path in vmtruncate() - limit checks are already
> done, but old i_size is still not lost...
The fs where it's important have mmu_private, that's what I use to decide
whethe
On Thu, 1 Mar 2001, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Mar 2001, Alexander Viro wrote:
>
> > +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> > +{
> > + struct page *page;
> > + unsigned long index, offset;
> > + int err;
> > +
> > + if (!mapping->a_ops
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> +{
> + struct page *page;
> + unsigned long index, offset;
> + int err;
> +
> + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write)
> +
On Thursday, March 01, 2001 12:05:50 PM -0800 Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> wrote:
>>
>> Alan, fix is really quite simple. Especially if you have vmtruncate()
>> returning int (ac1 used to do it, I didn't check
On Thu, 1 Mar 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >
> >Alan, fix is really quite simple. Especially if you have vmtruncate()
> >returning int (ac1 used to do it, I didn't check later ones). Actually
> >just a generic_cont_
In article <[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>Alan, fix is really quite simple. Especially if you have vmtruncate()
>returning int (ac1 used to do it, I didn't check later ones). Actually
>just a generic_cont_expand() done on expanding path in vmtruncate()
>will be
On Thu, 1 Mar 2001, Alan Cox wrote:
> > In that case, why was it changed for FAT only? Ext2 will still
> > happily enlarge a file by truncating it.
>
> ftruncate() and truncate() may extend a file but they are not required to
> do so.
>
> > If the behavior has to be changed, wouldn't it be be
> In that case, why was it changed for FAT only? Ext2 will still
> happily enlarge a file by truncating it.
ftruncate() and truncate() may extend a file but they are not required to
do so.
> If the behavior has to be changed, wouldn't it be better to first
> give people a chance to get programs,
On Thu, 1 Mar 2001, Peter Daum wrote:
> In that case, why was it changed for FAT only? Ext2 will still
> happily enlarge a file by truncating it.
Basically, the program depends on behaviour that was never guaranteed to
be there.
> Staroffice (the binary-only version; the new "open source"
> v
On Sun, 25 Feb 2001, Alan Cox wrote:
> > The bug with truncate in the fat filesystem that was present in 2.4.0,
> > and fixed with the 2.4.0-ac12 (or earlier) patch is still in the main
>
> It isnt a bug. The fix in 2.4-ac I've dropped. A program that assumes
> ftruncating a file large will work
> The bug with truncate in the fat filesystem that was present in 2.4.0,
> and fixed with the 2.4.0-ac12 (or earlier) patch is still in the main
It isnt a bug. The fix in 2.4-ac I've dropped. A program that assumes
ftruncating a file large will work is broken.
Alan
-
To unsubscribe from this li
The bug with truncate in the fat filesystem that was present in 2.4.0,
and fixed with the 2.4.0-ac12 (or earlier) patch is still in the main
(unpatched) kernel, both 2.4.1 and 2.4.2. The problem is that I cannot
apply the 2.4.0-ac patch to the newer kernels and I cannot patch up to
2.4.1 from 2.4
13 matches
Mail list logo
