berryzplus

@rom-k さん 参考情報あざっす。 極論するとギリギリのタイミングまで SetCurrentDirectory しなければいいだけなので、対応は可能だと考えています。 呼んだらアウトなんだから、呼ばなきゃいいのです :smile: あ、なんかsympathy...orz

> 「カレントディレクトリ」以外の仕組みでディレクトリ情報をどこかに保持しておけば良いのでは、と思います。 既にそういう構造だった気がします。 ちょっと今確認できないですが CEditDoc あたりにパスを保持する変数がいた気がします。 ※CEditDocは依存クラスが多いので、依存クラスのどれかだったかもしれないです。 なので、必要になるまでカレントディレクトリをセットしない対応は可能なはずです。 排他ロックなしモードで編集中ファイルがフォルダごと削除された場合の挙動としては、 ディレクトリを復活させるのではなく、設定した初期保存用ディレクトリを表示するのがよい気がします。

@ds14050 さん > 共通設定>編集>ファイルダイアログの初期位置、が > •カレントフォルダ 詰んだじゃないですかｗ 作業フォルダに指定されたフォルダが存在しない場合（＝起動後に消された）、 「作業フォルダｘｘｘは存在しません。作成しますか？」みたいに問い合わせするのが 親切な気がしてきました。

報告されていないCMemoryの不具合と考えられます。 エディタに文字を表示するためのメモリ（上限は2GB、スレッドヒープに存在） 　上限2GBは「1行あたり」の制約なので可能。 　👇 コピーの前準備としてメモリにコピー（上限は2GB、スレッドヒープに新たに確保） 　intでは3.81GBを表現できないので1メモリに詰め込もうとすると失敗します。 対策には以下3つが必要と思います。 1. CMemoryの内部的なサイズ型をsize_tに変更する修正。（影響小） 2. CMemoryに設定するデータ型をsize_tに変更する修正。（影響中） 3. CMemoryが返却するサイズ型をsize_tに変更する修正。（影響極大）

> CNativeW : public CNative : protected CMemory という形の継承階層ですが、特に CNativeW は各所で使われているので影響範囲がとても広くて対処が難しいですね。例えば各行の実データの `CDocLine::m_cLine` とかでです。 > > 1行の上限が2GBという制約は問題ないと思います。ただ64bitビルドでは4GBより大きいサイズのデータを各所で扱えるようにはしたいですね。 > > `CMemory` で `size_t` 型を使うと64bitビルドでインスタンスのサイズが増加してしまうのは嫌だなって思います。ただ大きなサイズのメモリを扱うために別の型を追加するのもちょっとどうなのか判断が付きかねます。。 issueを解決する方向としては、 一時バッファの確保方法を変更して 2GB超 を確保できるようにするのと GlobalAlloc に 2GB超 のデータを渡せるようにする感じかな、と思っています。...

冷静にコードを眺めると、1行に保持できる「データ量」の上限が2GBでした。 データ量＝2GB（2ギガバイト） 文字数（1文字あたり2bytes）＝1G文字

## 概要 この件「64bit版で2GBより大きいサイズのテキストのコピペをする事が出来ない」について、 あるべき結論の認識が変わったので書いておきます。 ## 結論 仕様です。 64bit版でも 2GB より大きいサイズのテキストを扱うことはできません。 扱えるテキストの最大サイズは、UTF16換算で `2G - 1` 文字 までです。 ## 結論の詳細 32bit版では、UTF16換算のテキストサイズが `2G - 1` 文字 に収まる場合でも、2GBを超えるファイルは開けません。 64bit版では、UTF16換算のテキストサイズが `2G - 1` 文字 に収まる場合に限り、2GBを超えるファイルを開くことができます。...

> 64bit版で読み込めるファイルサイズの上限が減ってしまうような変更は行わない方が良いと思いますよ。 たぶん誤解だと思いますが、新たな制限を作る話ではなく、仕様的な限界を明示しよう、って話です。 状況まとめ GitHub移行以前　メモリ上限は2GB、扱える文字数の上限は1G文字、32bit版では2GBを超えるファイルは開かない。 CMemory変更後　メモリ上限は4GB、扱える文字数の上限は2G文字、32bit版では2GBを超えるファイルは開かない。 ファイルサイズを制限する意味はないですね。 2GB上限を超えた場合に使う変な名前の関数も撤廃したいっすね（闇 一度に編集できる文字数に上限を定める「べき」の論拠は、 Text Services Frameworkが2G文字を超えるテキストの編集に対応していないからです。 https://docs.microsoft.com/ja-jp/windows/win32/api/textstor/nf-textstor-itextstoreacp-gettext 拡張形式として、2G上限を突破する手段があってもよいとは思います。 上限を超える方法を用意するかどうかは別にして、上限は設けるべきだと思います。

> [#1575 (comment)](https://github.com/sakura-editor/sakura/issues/1575#issuecomment-835138576) に書かれた「仕様」というのは、このぐらいまでのサイズのデータなら各処理で問題なく扱うことが出来るサイズなのかもしれません。しかし実際には場所毎に扱う事が出来るサイズというのは異なるので、もっと大きいサイズのファイルも構成によっては読み込んで表示する事が出来ると思います。 具体的な値を示してあるために、分かりづらかったかも知れません。 記載しているファイルサイズは目安です。 ドキュメント全体の上限文字数を定めたら、 快適に編集できる環境を提供できるんじゃないか？ と言う提案のつもりです。 現状は1.38GBを開けると言っても使用に耐えない重さです。 「開ける」なら、快適に編集できたほうがいいと思います。 > 現状の実装の問題点とまっとうな対策案は berryzplusさん自身が書いたコメント [#1575 (comment)](https://github.com/sakura-editor/sakura/issues/1575#issuecomment-793831350) にまとめられていると思います。どうしてそこから後退してしまったのか分かりません。問題の解決を急いでいるのでしょうか？ ぼくも当初は、サイズ値を64bit化するのが「まっとう」だと思っていました。 しかし、CNativeWのサイズ値を64bit化する対応では、4GB超のメモリが必要なときに、メモリをスレッドヒープから確保することになってしまうので、パフォーマンスに激しい悪影響が出そうだ、ということに気付きました。 で、ドキュメントデータの確保先がヒープでなくても構わない手法として、以前から導入検討していたtsfのCOMインターフェースのシグニチャを確認したところ、tsfが64bit対応してないことに気付きました。 それはそれとして、元々の事象（＝無応答になる）はバグとして対処するのが良いと思います。 編集上限文字に制限をかけたからと言って、無応答をなかったことにはできないですし。

しばらく考えてみました。 `content-type` が `text/plain` でも2GBを超えたらもうテキストじゃない気がします。 対応は、それを踏まえて行いたいです。 ---- こないだ2chの書き込みでこんなやりとりを見ました。 > 具体的にはどのくらいのファイルサイズ？ > 10GBくらい ・・・。 個人的には、500MBを超えたらログファイルじゃないような気がします。 何故かというと「メモ帳(=notepad.exe)」で開ける上限が500MBだからです。 「ログファイルじゃない」というより、「ログファイルとして使い物にならない」ってことですが。 ログファイルは、運用環境のシステムイベントを記録しておき、トラブルの対策に役立てるためのものです。 運用環境にインストールするプログラムは、ほとんどの場合「システムに必要なもの」に限られます。 ログファイルを見るためのプログラムが「システムに必要」と言えるかは微妙だと思います。 運用保守に余計なプログラムを要さないことは、一般的なシステムの非機能要件だと考えるからです。 10GBを超えるようなログファイルは、おそらくデバッグトレースの垂れ流しを記録した場合とかにできると思います。 たぶん、システム屋がやるべきことは、 10GBを超えるような自称「ログファイル」を吐くクソシステムに、 「それはシステムじゃねぇよ」とNOを叩きつけることだと思うんです。