問題タブ [dotnetzip]

zipファイルを返そうとしています

しかし、それに応じてエラーを返します（XMLで）：

XML解析エラー：要素が見つかりません場所：moz-nullprincipal：{122aa411-1418-43f5-b950-4347af7c7217}行番号1、列1：

（DotNetZipを使用するzipファイルへの）応答の何が問題になっていますか？

DotNetZip がファイルで車輪を回転させる理由について説明できる人はいますか? 私はこのファイルを持っていますが、これは著作権で保護されていて配布できず、zip 形式ではありません。ファイルの以前のバージョンまたはそれ以降のバージョンを使用できますが、正常に圧縮されます。

zip ユーティリティはバージョンを気にするべきではないので、ファイルが何らかの形で破損していると考えていると思います。この問題をデバッグするにはどうすればよいですか? コードをステップ実行すると、問題は発生しませんが、そのまま実行すると、この特定のファイルの保存時に停止します。ライブラリのコードは次のとおりです。

そのループにブレークポイントを置き、各ファイルを個別に保存すると、「不良ファイル」が表示されてもチョークしません。

何かご意見は？よろしくお願いします！

編集1：

明確にするために、「チョーク」と言うときは、ある種の無限ループに入り、「不良ファイル」を圧縮して残りのファイルに移動することを続行しないことを意味します。また、これは多くの人が使用しているファイルなので、破損していないはずです。

編集2：

以下に絞り込みました。

その圧縮モードが問題の原因です。これはある種のバグだと確信しています。もう 1 つの圧縮方法である Bzip2 は、非常に低速です。これをどのように回避するかはまだわかりません。

編集3：

DotNetZip は実に奇妙です。圧縮レベルを次のように調整して修正しました。

これで問題は解決しましたが、数分後に戻ってきて、機能しなくなりました。Bzip2 はまだ動作しますが、前に述べたように、信じられないほど遅いです。そこで、ZipFile API の他の部分をいじり始め、これを追加しました。

これで動作するようになりました。バグが本当に何であるかわかりませんか？

現在、ユーザーが最大6つのディレクトリを入力できるようにするソフトウェアを作成しています。各ディレクトリは文字列として（配列内に）保存され、ループは配列とnullではないものをすべてチェックすることを目的としています。ディレクトリが割り当てられている場合は、独自のアーカイブに圧縮されることを意図しています。これは私がこれまでに持っているコードです。

これを実行しようとしているのは、場所を指定された最初のユーザーを tmpZip0.7z に保存し、2 番目のユーザーを tmpZip1.7z に保存することですが、現時点では、各ディレクトリを tmpZip0.zip に追加するだけです。

また、補足として、アーカイブするように選択されたディレクトリの後に各アーカイブに名前を付けるにはどうすればよいですか?

現在 DotNetZip (Ionic.Zip) dll を使用しています。

十分な情報を提供したことを願っています。

コードから zip ファイルを作成しようとしています。dotnetzipを使用しています。

ディスク上に存在しないフォルダにディレクトリ ツリーを作成したい。どうすればいいですか？

使用してみAddDirectoryましたが、これはディスク上のディレクトリを見つけたいようです。AddEntry も試しましたが、これにはいくつかのコンテンツが必要です。

私のファイルは、FileStream オプションを使用して SQL Server に保存され、そこで階層化されています。

それを行うためにこの再帰的な方法を書きましたが、 AddDirectory 行は機能しません。

自己解凍型のexeを作成しようとしています。作成しても問題ありません。私が問題に直面しているのは

• exeファイルが存在する場所に抽出パスを設定する
• 抽出したexeファイルを実行します。

2番目の部分では、抽出パスを正しくする必要がある可能性が最も高くなります。DotNetZipLibraryから次の変更されたコードを使用しています

ファイルが作成され、サイズは問題ないようですが、ダブルクリックすると、形式が間違っているか、ファイルが破損していると表示されます。

これは私が使用しているコードです

次に、呼び出し元のメソッドで

getDocument（）は内部でCompressを呼び出します

そしてついにその方法

何か案は？前もって感謝します！ギレルモ。

DotNetZip ライブラリで奇妙なパフォーマンスの問題が発生しています。

アプリケーション (asp.net で実行) では、データベースから一連のファイルを読み取り、ユーザーがダウンロードできるようにオンザフライで zip ファイルにパックします。

私の開発用ラップトップではすべて正常に動作します。デフォルトの圧縮率で約 10MB の zip ファイルは、完了するまでに約 5 秒かかります。ただし、顧客の開発サーバーでは、同じファイル セットを圧縮するのに約 1 ～ 2 分かかります。私はさらに長い時間、数分まで経験しました。zip 実行中の CPU 使用率は 100% ですが、それ以外はほぼ 0% のままで、過負荷ではありません。

さらに興味深いのは、実稼働サーバーでは、完了するまでに約 20 秒かかることです。

どこから探し始めるべきですか？

いくつかのハードウェア仕様:

私のノートパソコン

2コア、4GB RAM専用のvirtualbox上で動作する開発環境。

• コア i5 M540 2,5GHz
• 8GBのRAM
• Win7

開発サーバー

マイコンピュータのプロパティダイアログによると（おそらく仮想化）

• インテル Xeon 5160 3GHz
• 540MBのRAM
• Windows 2003 サーバー

タスク マネージャー レポート シングル コア

本番サーバー

マイコンピュータのプロパティダイアログによると（おそらく仮想化）

• キセノン 5160 3GHz
• 512MBのRAM
• Windows 2003 サーバー

タスク マネージャー レポート デュアル コア

更新 サーバーは VMWare ホスト上で実行されています。タスクバーに隠れている VMWare アイコンを見つけました。

複数のzipファイルに分割する必要がある大きなzipファイルがあります。現在作成しているメソッドには、Listオブジェクトがあります。

これは私が持っているコードです：

そしてこれは私がsave（）呼び出しで得るエラーです：

{Ionic.Zlib.ZlibException：Ionic.Zlib.ZlibCodec.Inflate（FlushType flash）at Ionic.Zlib.InflateManager.Inflate（FlushType flush）at Ionic.Zlib.ZlibBaseStream.Read（Byte []バッファ、Int32オフセット、Int32カウント）at Ionic.Zlib.DeflateStream.Read（Byte []バッファ、Int32オフセット、Int32カウント）at Ionic.Crc.CrcCalculatorStream.Read（Byte []バッファ、Int32オフセット、Int32カウント）at Ionic .Zip.SharedUtilities.ReadWithRetry（Stream s、Byte [] buffer、Int32 offset、Int32 count、String FileName）at Ionic.Zip.ZipEntry._WriteEntryData（Stream s）at Ionic.Zip.ZipEntry.Write（Stream s）at Ionic .Zip.ZipFile.Save（）at Ionic.Zip.ZipFile.Save（Stream outputStream）at

私は何が間違っているのですか？

ASP.NET アプリケーションで DotNetZip ライブラリを使用して zip ファイルを作成し、保存しようとしています。しかし、何らかの理由で私は

パスへのアクセスが拒否されました

保存しようとするとエラー。

を別のフォルダーに変更し、TempFileFolderアクセス許可を与えました。まだ運がありません。

質問を見つけましたが、答えは役に立ちませんでした。

上記の質問から、1つの回答が言及されました：

また、あなたの例の tempFilePath にはフルパスが含まれていません.ZIPをあなたが期待している(そしてアクセス許可を割り当てられている)ものとは別のフォルダーに保存しようとしている可能性がありますか?

TempFileFolderとして言及したにもかかわらず、保存しようとしているフォルダーを特定する方法はD:\temp\?

何かご意見は？

I'm working on a system where I have a Stream (which is seekable) that I am reading a ZIP file from, then am writing the modified ZIP file back to that stream. Doing so results in a corrupt file. This can be demonstrated using the following code: