[fpc-pascal] TFileStream.SetSize sometimes fails

[Michael Van Canneyt]

On Thu, 13 Aug 2009, Mattias Gaertner wrote:

> On Thu, 13 Aug 2009 21:46:23 +0200 (CEST)
> Michael Van Canneyt <michael at freepascal.org> wrote:
>
>>
>>
>> On Thu, 13 Aug 2009, Mattias Gaertner wrote:
>>
>>>
>>> I want to replace the content of an existing file (keeping the type
>>> and rights). I used:
>>>
>>> fs := TFileStream.Create(Filename, fmOpenWrite or fmShareDenyNone);
>>> fs.Size := 0;
>>> fs.Write(.....);
>>> fs.Free;
>>>
>>> But it does not always work. The line fs.Size does not clear the
>>> file on every file system. So the fs.Write only replaces the first
>>> part of the file.
>>
>> If it depends on the filesystem, then you should complain with the
>> linux kernel people ?
>
> I'm not sure if it is a kernel thing. I don't have a vbox to test.
> That's why I ask. Maybe someone knows more.
>
>
>> Size=0 results in a ftruncate(Handle,0) call
>>
>> Part of a strace (ex20 from the baseunix unit docs, fptruncate call)
>>
>> open("test.dat", O_WRONLY|O_LARGEFILE)  = 3
>> ftruncate(3, 60)                        = 0
>> close(3)                                = 0
>>
>> So we can state that FPC's ftruncate does work, it passes the args to
>> the kernel. If the kernel does not actually truncate the file, there
>> is little FPC can do.
>
> Yes. The code worked pretty well for years on many systems. But
> you know the story of the ext4 bug. I hope this is not something like
> that.

I don't know the story of the ext4 bug, I can only say that the Size=0
gets translated to ftruncate(handle,0), which, if it works as described,
should set the file size to zero.

If it does not - no matter what the circumstances - it is a kernel bug,
not an FPC bug.

>
>
>> Why not simply remove/backup and subsequently recreate the file ?
>
> This will loose the access rights and type of the file.

Why does that matter ? I don't think the IDE needs to preserve these.

If the IDE needs to regenerate some files, it is natural that this would 
happen. I can imagine an option 'mode for new files', but that's as 
far as it goes, and in each case it will be limited by whatever the 
umask() function has set.

The IDE fails already on more simple matters:

Try saving a project file in the IDE which has been set to read-only.
The IDE will complain about the lpi file, and the 'Retry' button hangs 
the IDE. (at least here on a Linux system). If I set the lpr file to
read-only, then the project lpr file is not saved at all with no warning 
whatsoever, but is marked as saved.

This does not bother me (they are corner cases IMHO, where problems can be
expected), I simply think the IDE should not try to be too smart.

Michael.