On Sat, 26 Jan 2002 22:48:42 -0500 (EST), you wrote:
On Sat, 26 Jan 2002, Guy L. Albertelli wrote:
All the following is on the 2.2.12-20 kernel:
"ftruncate" would return a 0. However Scandisk said that the file was bad. The length reported in the directory was larger than the allocated space. Errors were also reported on attempts to move or copy the file.
Since ftruncate did not return a error, the rest of your code was never executed. So the rewrite basically asked if the file was being extended, then use the lseek and write. Use ftruncate only if shortening the file. This process resulted in a "valid" file. The size in the directory seemed to match the allocated space.
... Why don't we just eliminate the middleman and use lseek and write unconditionally? Just because ftruncate works on other than fat filsesystems doesn't mean we have to use it, does it? If we keep this up we will crack a walnut with a piledriver and 2 feather pilows.
You still need ftruncate in case the file has to shrink. To do that without ftruncate takes a lot more work then an lseek and a write.
Rein.