[
スレッド全体
]
▼
2008/11/24 (月) 02:31:18
なすこじ
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
[5472]
Re3:ANSI版の更新履歴について
#2002211を更新しました。
--
チェックをDoModal...()の関数からGetOpenFileNameRecover()/GetSaveFileName
Recover()
に移動しました。
また、バックアップファイル作成時のファイルパスもチェックするようにしました。
前回は気が付きませんでしたが、上書き確認の後にパス長確認になっています。
なので、フックを使わない場合上書き確認でOKした後パス長でエラーとなります。
フックを使う場合、プロシージャ内で_MAX_PATH未満にパスを切り詰めているので
上書き確認できず、たまたまパス長エラーだけが表示されます。
(切り詰めたパス名と同名ファイルがあると上書き確認される)
セーブダイアログは必ずフックを使用しプロシージャ内でもパス長チェックする
のが理想的と思いますが、今回そこまでは修正していません。
260バイト以上のパス長のファイルは、"C:\a"のような1文字フォルダに長い
ファイル名のファイルを作成しフォルダ名を変更すると作成可能です。
--
悩ましい感じもするので、長引くようなら#2002211は次回リリースに持ち越しましょう (^^;
▼
2008/11/24 (月) 12:35:48
ryoji
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SV1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
[5474]
Re4:ANSI版の更新履歴について
> 悩ましい感じ
気付いちゃったのね(^^;;;
▼
2008/11/24 (月) 14:05:14
げんた
INCM1.23c
[5475]
Re4:ANSI版の更新履歴について
>前回は気が付きませんでしたが、上書き確認の後にパス長確認になっています。
>なので、フックを使わない場合上書き確認でOKした後パス長でエラーとなります。
>フックを使う場合、プロシージャ内で_MAX_PATH未満にパスを切り詰めているので
>上書き確認できず、たまたまパス長エラーだけが表示されます。
>(切り詰めたパス名と同名ファイルがあると上書き確認される)
OFNHookProc()のcase CDN_FILEOK: 処理のところですね.確かに...
>セーブダイアログは必ずフックを使用しプロシージャ内でもパス長チェックする
>のが理想的と思いますが、今回そこまでは修正していません。
まあ,微妙なところなのでこのままでも良いのではないでしょうか.
>260バイト以上のパス長のファイルは、"C:\a"のような1文字フォルダに長い
>ファイル名のファイルを作成しフォルダ名を変更すると作成可能です。
作成可能ではありますが,Windowsにアクセスを拒否されるみたいです.
--
もう一点,普通はやらないと思いますが,バックアップの詳細設定を使用して(CEditDoc::FormatBackUpPath()のm_bBackUpPathAdvanced=1の場合),たとえば $0_$0_$0_$0_$0_$0_$0_$0_$0_$0といったパターンが指定されると,バックアップ文字列がファイル名の何倍にもなり,1024バイトの内部バッファを突破して悲しいことになります.ですので,厳密に言えばCEditDoc.cppの1747行目付近のファイル名・ディレクトリ名置換,および1778行目の拡張子置換の各ループ毎に長さチェックが必要だと思います.
▼
2008/11/25 (火) 15:44:36
なすこじ
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
[5476]
Re5:ANSI版の更新履歴について
▼ げんたさん
> >セーブダイアログは必ずフックを使用しプロシージャ内でもパス長チェックする
> >のが理想的と思いますが、今回そこまでは修正していません。
> まあ,微妙なところなのでこのままでも良いのではないでしょうか.
そうですね。元々_MAX_PATHを超えないようにしてあったのでこのままにしておきます。
> >260バイト以上のパス長のファイルは、"C:\a"のような1文字フォルダに長い
> >ファイル名のファイルを作成しフォルダ名を変更すると作成可能です。
> 作成可能ではありますが,Windowsにアクセスを拒否されるみたいです.
ファイル名に2バイト文字があればいけるのではないでしょうか?
私の所のWin2k SP4では、266バイトのパス長のファイルがunicode版で編集可能です。
> もう一点,普通はやらないと思いますが,バックアップの詳細設定を使用して(CEditDoc::FormatBackUpPath()のm_bBackUpPathAdvanced=1の場合),たとえば $0_$0_$0_$0_$0_$0_$0_$0_$0_$0といったパターンが指定されると,バックアップ文字列がファイル名の何倍にもなり,1024バイトの内部バッファを突破して悲しいことになります.ですので,厳密に言えばCEditDoc.cppの1747行目付近のファイル名・ディレクトリ名置換,および1778行目の拡張子置換の各ループ毎に長さチェックが必要だと思います.
対処したパッチを作成しました。
ではでは。
▼
2008/11/25 (火) 23:48:02
げんた
INCM1.23c
[5478]
Re6:ANSI版の更新履歴について
>> 長さチェックが必要だと思います.
>対処したパッチを作成しました。
確認しましたが,拡張子置換でのエラーチェックで break が抜けているようです.
それ以外はOKかと思います.
▼
2008/11/26 (水) 00:35:37
なすこじ
Mozilla/4.0 (compatible; MSIE 6.0; KDDI-MA33) Opera 8.60 [ja]
[5480]
Re7:ANSI版の更新履歴について
▼ げんたさん
> >> 長さチェックが必要だと思います.
> >対処したパッチを作成しました。
> 確認しましたが,拡張子置換でのエラーチェックで break が抜けているようです.
> それ以外はOKかと思います.
何度もすみません m(_ _)m
明日修正します。
▼
2008/11/26 (水) 23:24:53
なすこじ
Mozilla/4.8 (Macintosh; U; PPC)
[5482]
Re7:ANSI版の更新履歴について
▼ げんたさん
> >> 長さチェックが必要だと思います.
> >対処したパッチを作成しました。
> 確認しましたが,拡張子置換でのエラーチェックで break が抜けているようです.
> それ以外はOKかと思います.
breakを追加しrev1474でコミットしました。
▼
2009/10/10 (土) 04:55:01
あろか
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
[5624]
Re8:ANSI版の更新履歴について
▼ なすこじさん
> breakを追加しrev1474でコミットしました。
バックアップの詳細設定を使用して、上位のフォルダを多く残すようにした場合、ファイルが浅い階層にあるときに sakura.exe が異常終了するようになっていました。
確認手順: $2\$1\$0 のように指定して C:\temp.txt を編集・保存する。
パッチ: #2875910 を作成しました。
[
▼次のスレッド
]
INCM/CMT
Cyclamen v3.81
[ut:0.010][st:0.000]