Talk:Truncate a file: Difference between revisions

From Rosetta Code
Content deleted Content added
Rdm (talk | contribs)
Line 8: Line 8:
::Quoting http://www.conifersystems.com/2008/10/21/windows-vs-unix-file-system-semantics/ '' '''The Windows delete and rename model is different.''' You wouldn’t know this from the Win32 APIs, but in order to delete or rename a file in Windows, you first have to open it! Once you’ve opened it can you call NtSetInformationFile with InformationClass of FileDispositionInformation or FileRenameInformation. Setting FileDispositionInformation doesn’t even delete the file; it merely enables delete-on-close for the file, and the delete-on-close request could very well be cancelled later.''
::Quoting http://www.conifersystems.com/2008/10/21/windows-vs-unix-file-system-semantics/ '' '''The Windows delete and rename model is different.''' You wouldn’t know this from the Win32 APIs, but in order to delete or rename a file in Windows, you first have to open it! Once you’ve opened it can you call NtSetInformationFile with InformationClass of FileDispositionInformation or FileRenameInformation. Setting FileDispositionInformation doesn’t even delete the file; it merely enables delete-on-close for the file, and the delete-on-close request could very well be cancelled later.''
::And, as near as I can tell, you have to get rid of the association between a name and a file before you can give another file that name. --[[User:Rdm|Rdm]] 14:43, 19 July 2011 (UTC)
::And, as near as I can tell, you have to get rid of the association between a name and a file before you can give another file that name. --[[User:Rdm|Rdm]] 14:43, 19 July 2011 (UTC)
::: I see, you are talking about the rename part. Truncating a file on windows works not very differently from unix. But it's true that unlike on unix where filename is just a link pointing to some inode, windows files are closely tied to the names, fair point. --[[User:Ledrug|Ledrug]] 14:55, 19 July 2011 (UTC)

Revision as of 14:55, 19 July 2011

So just to be sure, if the actual file size is smaller than the given truncated size, it's an error? It doesn't just leave the file alone? --Mwn3d 14:09, 19 July 2011 (UTC)

POSIX truncate() and ftruncate() extends the file if specified size is larger than original. It's convenient when you want to reserve some disk space. --Ledrug 14:25, 19 July 2011 (UTC)

Assumes unix

It's pretty clear that this task assumes unix file system semantics. So, can we ignore other operating systems in this task? --Rdm 14:33, 19 July 2011 (UTC)

Why is it clear the task assumes unix behavior? --Ledrug 14:37, 19 July 2011 (UTC)
Quoting http://www.conifersystems.com/2008/10/21/windows-vs-unix-file-system-semantics/ The Windows delete and rename model is different. You wouldn’t know this from the Win32 APIs, but in order to delete or rename a file in Windows, you first have to open it! Once you’ve opened it can you call NtSetInformationFile with InformationClass of FileDispositionInformation or FileRenameInformation. Setting FileDispositionInformation doesn’t even delete the file; it merely enables delete-on-close for the file, and the delete-on-close request could very well be cancelled later.
And, as near as I can tell, you have to get rid of the association between a name and a file before you can give another file that name. --Rdm 14:43, 19 July 2011 (UTC)
I see, you are talking about the rename part. Truncating a file on windows works not very differently from unix. But it's true that unlike on unix where filename is just a link pointing to some inode, windows files are closely tied to the names, fair point. --Ledrug 14:55, 19 July 2011 (UTC)