Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <00af01c4403b$42c1c5e0$64fda287@docbill002> From: "Bill C. Riemers" To: References: <6 DOT 1 DOT 0 DOT 6 DOT 0 DOT 20040521150946 DOT 03262f68 AT pop DOT theworld DOT com> <20040521192359 DOT GA6832 AT coe DOT bosbc DOT com> <20040521203759 DOT GB7790 AT coe DOT bosbc DOT com> <00ba01c43f74$50560f30$64fda287 AT docbill002> Subject: Re: ftruncate64() question? Date: Sat, 22 May 2004 16:24:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes > What's wrong with ftruncate? ftruncate fails with files larger >= 2GB because off_t gets interpreted as 32 bit signed integer... I can find some archived cygwin messages referencing bug fixes to ftruncate64 in the cygwin.dll. However, using ftruncate64 results in an unresolved symbol. In fact based on those messages, I inserted the following code in my program as a workaround for a truncate64() function: #if defined(__CYGWIN__)||defined(__GW32__) __int64 truncate64(const char *filename,__int64 newFileSize) { DWORD dw; HANDLE h=CreateFile(filename,GENERIC_WRITE,0,NULL,OPEN_ALWAYS,0,NULL); DeviceIoControl(h,FSCTL_SET_SPARSE,NULL,0,NULL,0,&dw,NULL); SetFilePointerEx(h,(LARGE_INTEGER)newFileSize,NULL,FILE_BEGIN); SetEndOfFile(h); CloseHandle(h); return newFileSize; } #endif This seems to work up to file sizes of 16TeraBytes, which for my purposes is more than adiquate. Bill -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/