> Fortunately, even in the Linux case, it doesn't seem to mess up quotas.
of course not. ls -ls the file. its just a few indirect blocks.
> The argument to [f]truncate is meant to be a size_t not a ssize_t, so
> probably this is a signed/unsigned bug.
actually its off_t, but that is indeed the problem. from
linux/fs/open.c, line 86:
asmlinkage int sys_truncate(const char * path, unsigned long length)
> The man page says that it should
> truncate a file to at most the specified size, so the correct behaviour
> should be
>
> truncate("x", -1)
> kernel: current size 0 < new size 2^32 - 1
> kernel: return success with no action
you are misreading the man page. to at most the *specified* length,
not the *current* length. on every unix, if you truncate() with a
length greater than the file currently has, it gets extended with a
hole.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:42:57 PDT