『+Lhaca 1.24』について 　<Feb.10,2008>

　+Lhaca が作成する書庫については以下の制限が存在します：

• 作成される書庫は h1 形式ヘッダーです。
• 基本は上記のとおりなのですが， 基本ヘッダーのファイル名項目 (のみ) で表現可能な 255 バイトまで作成を行ってしまうため， 自身を含めて取り扱い不可能な書庫が作成されてしまいます。 ヘッダー読み込み時のリカバリーは行われませんので， 当該箇所以降の全てのメンバーは無視されます。
• h1 形式ヘッダーであることから， タイムスタンプについては全て ftime 形式 (2 秒単位) の切り捨てで扱われます。
• 属性ヘッダーに対応していないため， 属性については情報が失われます。

　属性ヘッダー (識別子 0x40) に対応していないため， h1/h2 形式ヘッダーについては属性が保存・復元されません。

　基本ヘッダーに記録されている情報のみ扱われます。 従って， 多くのツールと同様， 更新日時のみ復元が行われ， h2 形式ヘッダー未満の書庫については， 通常は NTFS ファイルシステムであっても ftime 形式 (2 秒単位) でタイムスタンプが扱われます。

　この辺りについては， オリジナルの LHA.EXE を含めた多くのアプリと同様となっていますので， 大きな問題は発生しないものと思われます。

　正常に扱われますが， タイムスタンプは多くのアプリと同様に復元されません。

　lh0 / lh4～lh7 形式が扱えます。 その他の形式については， 扱うことができません。

　メソッド ID と実際のメソッドが異なるメンバー (lh6 と lh7 形式メソッドの区別されていなかった時期が存在するため， そのような書庫が存在します。) の主なものについては， 以下のとおりです：

　h0/h1 形式が扱えます。

　h2 ヘッダー形式書庫の取り扱いについては以下の制限が存在します：

• 内部ルーチンが h0 形式を基本としているため， ヘッダーサイズが正常に取り扱われません。 従って， パスが長い場合などヘッダー全体が 255 バイトを超えたものについては扱えず， リカバリーも行われないため， 以降のメンバーが全て無視されます。
• +Lhaca はヘッダー CRC に対応していないため， ヘッダー改竄・破損の確認が行われません。 攻撃書庫の多くはヘッダー改竄を伴っていますので， そういった意味では危険性が高いと言えます。

　+Lhaca では基本ヘッダーの SUM チェックしか行われず， ヘッダー CRC については作成も読込も行われません。 従って， h2 形式の全て， 多くの h1 形式， そして (Linux 上などで作成された) h0 形式の書庫については， ヘッダー改竄・破損の確認が行われません。 攻撃書庫の多くはヘッダー改竄を伴っていますので， そういった意味では危険性が高いと言えます。

　+Lhaca ではメンバー (格納ファイル) についての CRC チェックが (実質) 行われません。 ルーチン自体は Lhaplus や 7-Zip 等と同じく「CRC エラーが発生した場合は， ファイルの削除を行わずエラーログの出力のみ行われる」ものになっていると予想されますが， ログの出力や表示が行われないため， チェックを行わない場合と全く同じ結果となってしまっています。 +Lhaca については， この点が一番大きな問題と言えそうです。

　絶対パスをもつものや， 親ディレクトリーを示す ".." のパス情報をもつメンバーについては， 指定したディレクトリー配下へ展開が行われるように調整が行われます。

　1000 文字といった長い名前をもったメンバー等の存在する書庫については， 展開されない (エラーログが出力される。) ようになっています。

　これらの不正なパス情報等をもったファイルについては以下のとおりです：