チケット #38225

Emulate _fseeki64()/_ftelli64() API on legacy platforms.

登録: 2018-04-21 23:26 最終更新: 2018-12-05 05:22

報告者:
担当者:
チケットの種類:
状況:
完了
コンポーネント:
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
受領
投票
点数: 3
100.0% (3/3)
0.0% (0/3)

詳細

Although 32-bit Windows has supported operations on files larger than 2GB, since at least WinNT4 and Win98, (and possibly earlier), Microsoft did not introduce the _fseeki64() and _ftelli64() APIs until MSVCR80.DLL, (and subsequently retrofitted it to MSVCRT.DLL, from WinVista onwards); prior to this, random access support in large files was provided through lower level APIs such as _lseeki64(), or native Windows API functions.

As noted in this mailing list query, and this subsequent follow-up thread, it is practicable to emulate the _fseeki64() and _ftelli64() APIs, such that they become available on legacy versions of Windows, which pre-date the formal introduction of these APIs by Microsoft; however, previous efforts to do so may not have been entirely robust. Hopefully, the attached patch will do a better job.

添付ファイルリスト

チケットの履歴 (9 件中 3 件表示)

2018-04-21 23:26 更新者: keith
  • 新しいチケット "Emulate _fseeki64()/_ftelli64() API on legacy platforms." が作成されました
2018-04-21 23:29 更新者: keith
  • 添付ファイル emulate-fseeki64.patch (File ID: 5396) が付加されました
2018-04-25 01:43 更新者: earnie
コメント

It would be extremely useful to be able to seek past the 2G limit MS has.

2018-10-10 06:04 更新者: keith
コメント

Reply To earnie

It would be extremely useful to be able to seek past the 2G limit MS has.

It always has been possible to do so, to the extent that _lseeki64() supports it; the problem is that the effect of _lseeki64() isn't reflected in __iob context, without some additional processing.

The patch I've proposed provides fall-back implementations of _fseeki64() and _ftelli64(), based on _lseeki64() and _telli64() respectively, with the additional processing required to propagate relevant effects to the associated __iob context. Unfortunately, while these fall-back implementations should be entirely suitable for deployment on all WinNT derived platforms, they are likely to be susceptible to the "write after seek beyond EOF" issue described in Mumit Khan's mingw-fseek.c, when deployed on Win9x; however, I do have reservations about the robustness of Mumit's work-around for this issue, which may thus benefit from review, and some rework.

2018-11-26 03:15 更新者: keith
コメント

I committed 09fb4c4, which should suffice to provide robust implementations of _fseeki64() and _ftelli64() for all WinNT derived platforms. They will also work on Win9x, but I'm leaving the ticket open for the time being, because, as I suspected, they will interact badly with fwrite() on these platforms, if the fwrite() is preceded by an _fseeki64() to an offset beyond the physical end of file.

2018-11-27 03:15 更新者: keith
コメント

I have performed a review of Mumit Kahn's mingw-fseek.c implementation; I observe several minor issues, and at least one critical issue. The critical issue is:–

  • The fseek() wrapper sets a flag, to indicate that it has been called; this flag is then reset on the next call to the fwrite() wrapper. In neither case is there any attempt to associate the flag with any particular stream, never mind to ensure that the fwrite() is directed to the stream on which the fseek() was performed. In consequence, it is entirely possible that the flag could have been reset before the fwrite() which needs to act on it is performed.

Besides this critical issue, other non-critical issues include:–

  • Unnecessary use of (ugly) low level Windows APIs, leading to excessive complexity of the implementation.
  • Unnecessary repeated calls to the _get_osfhandle() API, within a single fwrite() wrapper call; this surely has a negative impact on performance.
  • Two fseek() wrapper functions, where one would suffice; (all fseek()-alike calls could be redirected a to single wrapper, in which a 64-bit offset argument is passed).
2018-11-27 06:20 更新者: keith
  • 添付ファイル win9x-fwrite-redirector.patch (File ID: 5440) が付加されました
2018-11-27 06:38 更新者: keith
コメント

I've attached a further patch; to resolve the issues I identified, within the Win9x fssek()/fwrite() redirector, it provides a complete reimplementation of that feature. Note that, to address the critical failing I described, in the original implementation of the redirector, it now maintains a queue of stream identifiers for which an fwrite() operation is pending, following an fseek() on the associated stream. This queue is implemented in terms of the POSIX.1-1996 linked-list queues API; as such, it is dependent on adoption of the feature request detailed on ticket #38770.

(編集済, 2018-11-27 06:40 更新者: keith)
2018-12-05 05:22 更新者: keith
  • 状況オープン から 完了 に更新されました
  • 担当者(未割り当て) から keith に更新されました
  • 解決法なし から 受領 に更新されました
コメント

I committed #2c98d6a; together with previous commits #09fb4c4, and #c27255f, this completes the _fseeki64()/_ftelli64() retrofit for both WinNT and Win9x platforms, and corrects the possible misbehaviour of an immediately subsequent fwrite(), on Win9x.

This retrofit will be included within the next WSL release.

編集

このチケットにコメントを追加するには、ログインが必要です » ログインする