アカウント名:
パスワード:
Gigazineの記事を読む限りハードリンク的なことをして容量を膨らましてるっぽい。FATでもハードリンクできるらしいし、参照先を同じにすればできるわな。同じファイルが含まれる場合ってちょくちょくあるだろうけど、普通に圧縮するときにそういう使い方することあるのかな。あるとすれば対策は難しそうだ。
ついでにあるエントリの何バイト目から何バイト目みたいな指定ができれば便利…どころじゃないな。ソリッド圧縮ができることになる。まぁ圧縮済みファイルを途中から読みだすのは大変だから工夫が多少は必要だけど。
FATの場合は通常クロスリンクと呼ばれていてファイルシステムのエラー扱いされる
ZIPは個々のエントリーの先頭にローカルファイルヘッダとは別にヘッダ情報だけをまとめたセントラルディレクトリがある。前者はシーケンシャルにしか存在できないが、後者は(本来別の)あるエントリの何バイト目から何バイト目みたいな指定ができる。そして、処理の効率化のためにセントラルディレクトリしか読まず、ローカルファイルヘッダを読まないプログラムは少なくない。
ローカルヘッダがあるのか。だからバイナリエディタで覗くとファイル名が見えるわけだな。対策もチェックするだけで簡単な話か。とはいってもローカルヘッダに見えるようずらして配置できるから、対策には頭から解凍しないといけないのでそれなりにコストがかかるな。
ソリッド圧縮的な使い方としては圧縮後での何バイト目かで指定できないといけないし、不正なファイルになるから使えないな。
ローカルファイルヘッダの情報がファイルサイズが0記録されているものもあるので、次のローカルファイルヘッダに行くためには、解凍の動作をしなければならないこともあります。(またはヘッダーを探す??)なので、やっぱりセントラルディレクトリでしょう。(サイズ0は、圧縮開始時には、サイズが不明なストリームタイプのデータとかに使われます。1パスで作成できる構造で、データを随時圧縮できる為、データ全体をどこかに置く必要もありません。)
関係ないけど、何故、パスワード付のzipの解凍は標準であるのに圧縮は、標準でないの?python,node.js,C#とか
Gigazineの記事を読む限りハードリンク的なことをして容量を膨らましてるっぽい。
圧縮側のアプリケーションが不適切だよね実態ではなくハードリンク|シンボリックリンク|ジャンクション自体をとらないとあかん
ハードリンク|シンボリックリンク|ジャンクション自体で圧縮されてるものでそれなら解凍側がハードリンク|シンボリックリンク|ジャンクション自体として扱ってないのがあかん
ってこんなん一昔前には対策済みですから圧縮アプリケーションが相当古いものかハードリンク|シンボリックリンク|ジャンクションを意図的に実態と誤認して扱う悪意あるアプリケーションかどっちでしょうね
# まぁそのあたりの容量算出がおかしなOSもあるから何ともだが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
ハードリンク (スコア:0)
Gigazineの記事を読む限りハードリンク的なことをして容量を膨らましてるっぽい。
FATでもハードリンクできるらしいし、参照先を同じにすればできるわな。
同じファイルが含まれる場合ってちょくちょくあるだろうけど、普通に圧縮するときにそういう使い方することあるのかな。
あるとすれば対策は難しそうだ。
ついでにあるエントリの何バイト目から何バイト目みたいな指定ができれば便利…どころじゃないな。ソリッド圧縮ができることになる。
まぁ圧縮済みファイルを途中から読みだすのは大変だから工夫が多少は必要だけど。
Re: (スコア:0)
FATの場合は通常クロスリンクと呼ばれていてファイルシステムのエラー扱いされる
Re: (スコア:0)
ZIPは個々のエントリーの先頭にローカルファイルヘッダとは別にヘッダ情報だけをまとめたセントラルディレクトリがある。
前者はシーケンシャルにしか存在できないが、後者は(本来別の)あるエントリの何バイト目から何バイト目みたいな指定ができる。
そして、処理の効率化のためにセントラルディレクトリしか読まず、ローカルファイルヘッダを読まないプログラムは少なくない。
Re: (スコア:0)
ローカルヘッダがあるのか。だからバイナリエディタで覗くとファイル名が見えるわけだな。
対策もチェックするだけで簡単な話か。
とはいってもローカルヘッダに見えるようずらして配置できるから、対策には頭から解凍しないといけないのでそれなりにコストがかかるな。
ソリッド圧縮的な使い方としては圧縮後での何バイト目かで指定できないといけないし、不正なファイルになるから使えないな。
Re: (スコア:0)
ローカルファイルヘッダの情報がファイルサイズが0記録されているものもあるので、
次のローカルファイルヘッダに行くためには、解凍の動作をしなければならないこともあります。(またはヘッダーを探す??)
なので、やっぱりセントラルディレクトリでしょう。
(サイズ0は、圧縮開始時には、サイズが不明なストリームタイプのデータとかに使われます。1パスで作成できる構造で、データを随時圧縮できる為、データ全体をどこかに置く必要もありません。)
関係ないけど、何故、パスワード付のzipの解凍は標準であるのに圧縮は、標準でないの?python,node.js,C#とか
Re: (スコア:0)
Gigazineの記事を読む限りハードリンク的なことをして容量を膨らましてるっぽい。
圧縮側のアプリケーションが不適切だよね
実態ではなくハードリンク|シンボリックリンク|ジャンクション自体をとらないとあかん
ハードリンク|シンボリックリンク|ジャンクション自体で圧縮されてるものでそれなら
解凍側がハードリンク|シンボリックリンク|ジャンクション自体として扱ってないのがあかん
ってこんなん一昔前には対策済みですから
圧縮アプリケーションが相当古いものか
ハードリンク|シンボリックリンク|ジャンクションを意図的に実態と誤認して扱う悪意あるアプリケーションか
どっちでしょうね
# まぁそのあたりの容量算出がおかしなOSもあるから何ともだが