truncate("x", -1)

• Previous message: Phillip Vandry: "Re: Plain text passwords--necessary"
• Next in thread: Ambrose Feinstein: "Re: truncate("x", -1)"
• Reply: Ambrose Feinstein: "Re: truncate("x", -1)"
• Reply: Chris Wedgwood: "Re: truncate("x", -1)"
• Reply: Florian Weimer: "Re: truncate("x", -1)"
• Reply: Pavel Kankovsky: "Re: truncate("x", -1)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Looks Linux specific from some testing.  And doesn't even happen with Linux
NFS to a Linux server.

  Digital Unix ADVFS - no problem
  Solaris UFS - no problem
  Linux 2.0 NFS client against Solaris NFS server (UFS) - no problem
  Linux 2.0 NFS client against Linux NFS 2.0 server (EXT2FS) - no problem
  Linux 2.0 EXT2FS - PROBLEM
  StarOS 4.1.1 TMPFS - no problem
  StarOS 4.1.1 UFS - no problem
  FreeBSD 3.0 - no problem
  NeXTStep 3.3 - no problem

Fortunately, even in the Linux case, it doesn't seem to mess up quotas.

The argument to [f]truncate is meant to be a size_t not a ssize_t, so
probably this is a signed/unsigned bug.  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

David.

(NB: StarOS 4.1.1 in the above list is basically SunOS 4.1.1 for one type of
sun4x [the Star 910/VP])

• Next message: Trevor Schroeder: "Re: Plain text passwords--necessary"
• Previous message: Phillip Vandry: "Re: Plain text passwords--necessary"
• Next in thread: Ambrose Feinstein: "Re: truncate("x", -1)"
• Reply: Ambrose Feinstein: "Re: truncate("x", -1)"
• Reply: Chris Wedgwood: "Re: truncate("x", -1)"
• Reply: Florian Weimer: "Re: truncate("x", -1)"
• Reply: Pavel Kankovsky: "Re: truncate("x", -1)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:42:49 PDT