Proposed resolution:

This wording is relative to N4713.

[Drafting note: I considered a slightly more verbose form: "Causes the size in bytes of the file p resolves to, as determined by file_size ([fs.op.file_size]), to be equal to new_size, as if by POSIX truncate." but I don't think it's an improvement. The intent of the proposed wording is that if either file_size(p) or truncate(p.c_str()) would fail then an error occurs, but no call to file_size is required, and file system races might change the size before any such call does occur.]

1. Modify [fs.op.resize_file] as indicated:

   void resize_file(const path& p, uintmax_t new_size);
   void resize_file(const path& p, uintmax_t new_size, error_code& ec) noexcept;
   

   -1- Postconditions: file_size(p) == new_sizeEffects: Causes the size that would be returned by file_size(p) to be equal to new_size, as if by POSIX truncate.

   -2- Throws: As specified in [fs.err.report].

   -3- Remarks: Achieves its postconditions as if by POSIX truncate().

[ 2018-3-17 Adopted in Jacksonville ]

[ 2018-1-26 issues processing telecon ]

Status to 'Tentatively Ready'

[ 2018-01-16, Jonathan provides wording ]

[ Issues Telecon 16-Dec-2016 ]

Priority 3

resize_file has this postcondition (after resolving late comment 42, see P0489R0):

Postcondition: file_size(p) == new_size.

This is impossible for an implementation to satisfy, due to the possibility of file system races. This is not actually a postcondition; rather, it is an effect that need no longer hold when the function returns.