Talk:Truncate a file: Difference between revisions

I think this is ready to be promoted to task
(Suggest to reword the file size requirement part)
(I think this is ready to be promoted to task)
 
(5 intermediate revisions by 3 users not shown)
Line 22:
::Truncating on windows is not a problem, just call <code>SetEndOfFile()</code> or <code>truncate()</code> (NT is actually POSIX.1 compliant). It's the renaming part that's inconvenient (still not a real problem). Another thing, the requirement that the routine should bail out if requested size is larger than original is unrealistic. If it's important that the file must be the requested size, you should extend it; if it's not important, why not just leave it alone and move on? If you really cared, you should have checked its size beforehand anyway. --[[User:Ledrug|Ledrug]] 17:21, 19 July 2011 (UTC)
:::Yeah, I would have expected a beforehand check here. However, for the purpose of this task, the truncation is the bit that I hoping to see demonstrated here, rather than determining the filesize. I don't have any objection to extending the file, if that is easier than bailing out. It would be nice to get a warning message that the file has been padded, or maybe we could just place a note against a the solution that the file gets padded, if the provided length is greater than the current length of the file. [[User:Markhobley|Markhobley]] 19:20, 19 July 2011 (UTC)
:::I don't know Microsoft Windows. If it supports truncation, then why is a rename required? Does the truncated file become disassociated with the original filename or something? Presumably, it is not just a simple open,truncate,close sequence involved here. [[User:Markhobley|Markhobley]] 19:38, 19 July 2011 (UTC)
:::::Yes, truncation is supported in the Win32 API. At issue, I thought, was the general compatibility of the rename step. I'd probably recommend leaving the temp-and-rename workaround out of it, if it's strictly truncation that's of interest. Or leave off the requirement of atomicity. Or assume that an delete step on the original file is allowed, if necessary. --[[User:Short Circuit|Michael Mol]] 20:44, 19 July 2011 (UTC)
::::::I've left the temp and rename workaround in, so that this can be implemented on systems that have no other mechanisms. A delete of the original file prior to rename is permissible. I have added that to the task description. [[User:Markhobley|Markhobley]] 20:56, 19 July 2011 (UTC)
:::Is NT still POSIX compliant? I thought that functionality was stripped out and shipped as Windows Services for UNIX, which operates under CSRSS as a different subsystem with bizarre interaction limitations. I could be wrong, of course. --[[User:Short Circuit|Michael Mol]] 20:46, 19 July 2011 (UTC)
::::NT4 and 2K were POSIX level 1 compliant. I think starting from XP some versions of Windows have POSIX layer by default, some don't. I'm not sure if SfU is the same as the POSIX subsystem: I thought SfU is a much more complete compatibility package. At least that's what I heard, but I haven't seriously used Windows for years. --[[User:Ledrug|Ledrug]] 21:04, 19 July 2011 (UTC)
 
I think this is ready to be promoted to task. [[User:Markhobley|Markhobley]] 17:27, 13 August 2011 (UTC)