SetFilePointerEx function

Expand
2 out of 7 rated this helpful - Rate this topic

SetFilePointerEx function

Applies to: desktop apps | Metro style apps

Moves the file pointer of the specified file.

Syntax

BOOL WINAPI SetFilePointerEx(
  __in       HANDLE hFile,
  __in       LARGE_INTEGER liDistanceToMove,
  __out_opt  PLARGE_INTEGER lpNewFilePointer,
  __in       DWORD dwMoveMethod
);

Parameters

hFile [in]

A handle to the file. The file handle must have been created with the GENERIC_READ or GENERIC_WRITE access right. For more information, see File Security and Access Rights.

liDistanceToMove [in]

The number of bytes to move the file pointer. A positive value moves the pointer forward in the file and a negative value moves the file pointer backward.

lpNewFilePointer [out, optional]

A pointer to a variable to receive the new file pointer. If this parameter is NULL, the new file pointer is not returned.

dwMoveMethod [in]

The starting point for the file pointer move. This parameter can be one of the following values.

ValueMeaning
FILE_BEGIN
0

The starting point is zero or the beginning of the file. If this flag is specified, then the liDistanceToMove parameter is interpreted as an unsigned value.

FILE_CURRENT
1

The start point is the current value of the file pointer.

FILE_END
2

The starting point is the current end-of-file position.

 

Return value

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks

The file pointer returned by this function is not used for overlapped read and write operations. To specify the offset for overlapped operations, use the Offset and OffsetHigh members of the OVERLAPPED structure.

You cannot use the SetFilePointerEx function with a handle to a nonseeking device such as a pipe or a communications device. To determine the file type for hFile, use the GetFileType function.

Use caution when setting the file pointer in a multithreaded application. You must synchronize access to shared resources. For example, an application whose threads share a file handle, update the file pointer, and read from the file must protect this sequence by using a critical section object or a mutex object. For more information about these objects, see Critical Section Objects and Mutex Objects.

If the hFile handle was opened with the FILE_FLAG_NO_BUFFERING flag set, an application can move the file pointer only to sector-aligned positions. A sector-aligned position is a position that is a whole number multiple of the volume's sector size. An application can obtain a volume's sector size by calling the GetDiskFreeSpace function. If an application calls SetFilePointerEx with distance-to-move values that result in a position that is not sector-aligned and a handle that was opened with FILE_FLAG_NO_BUFFERING, the function fails, and GetLastError returns ERROR_INVALID_PARAMETER. For additional information, see File Buffering.

Note that it is not an error to set the file pointer to a position beyond the end of the file. The size of the file does not increase until you call the SetEndOfFile, WriteFile, or WriteFileEx function. A write operation increases the size of the file to the file pointer position plus the size of the buffer written, leaving the intervening bytes uninitialized.

You can use SetFilePointerEx to determine the length of a file. To do this, use FILE_END for dwMoveMethod and seek to location zero. The file offset returned is the length of the file. However, this practice can have unintended side effects, such as failure to save the current file pointer so that the program can return to that location. It is simpler and safer to use the GetFileSizeEx function instead.

You can also use SetFilePointerEx to query the current file pointer position. To do this, specify a move method of FILE_CURRENT and a distance of zero.

Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

FileAPI.h (include Windows.h);
WinBase.h on Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

See also

File Management Functions
GetDiskFreeSpaceEx
GetFileSizeEx
GetFileType
SetEndOfFile
WriteFile
WriteFileEx

 

 

Send comments about this topic to Microsoft

Build date: 5/5/2012

Did you find this helpful?
(1500 characters remaining)
Community Additions ADD
More FILE_FLAG_NO_BUFFERING caveats

When using FILE_FLAG_NO_BUFFERING:

1) You cannot, in general, get the file size by doing a zero seek relative to FILE_END. The end of the file may not coincide with a sector boundary and trying to seek to a non-aligned position (even if you are just trying to find out what that position is) is illegal and will fail.

2) If you use a ReadFile loop to read a file whose size is not an exact multiple of the sector size, the final read will be "short" and the file pointer will be left in an illegal position. The file pointer is left pointing to the byte after the last byte in the file, and that is not on a sector boundary.

3) As a consequence of 2, you cannot, in general, discover the current file position by doing a zero seek relative to FILE_CURRENT. If the current position is already illegal, then it is illegal to ask Windows to seek to the current position (which is what a zero seek does); the call will fail and won't tell you where you are.

The 1st thing is easy to work around by using GetFileSizeEx instead.

I am not aware of any APIs to work around the combination of the 2nd and 3rd things. You may need to do the bookkeeping yourself, making a note of the current file position before each ReadFile call, then adding on the number of read bytes read so that you know the new (possibly illegal) file position. While the filesystem's internal bookkeeping stores this information, there doesn't seem to be a query-only GetFilePointer API to work around the issue of SetFilePointerEx erroring even on seek which does not move the pointer when the pointer is already, due to the filesystem itself, in an illegal position.

5/12/2012