操業停止により起こりうる電力不足に対応するため、イグナリナ原発と同じ場所に新たな原発を建設するべきだという議論が1990年代から2000年代にかけて起こった。2006年2月27日にトラカイでおこなわれたバルト三国首相会合で、3カ国はそれぞれの国営電力会社に対してリトアニアの新原発建設計画に投資するよう働きかける旨の公式声明を発表した。2007年6月28日、リトアニア議会は新原発建設のための新法を成立させ、建設は実行に移されることとなった。2008年7月30日、リトアニア・ラトビア・エストニア・ポーランドの電力会社は、3,000〜3,200ワットの電力を供給する新原子力発電所の建設に向けて、ヴィサギナス原子力発電所会社の開業に同意した。新原発の操業開始は2015年〜2018年になるものとみられている。なお、エストニアのアンシップ首相とエストニア電力のリーヴェC.E.O.は2008年10月31日、「エストニアが原子力発電の道を選択するのであれば、独自建設の路線が優先される」と述べ、リトアニアの新原発建設計画参加よりも自国の原発建設を優先することを示唆している。その後2010年に新たな原子力発電所の建設に向け入札を行ったが、唯一応札した韓国電力公社 (KEPCO)が応札を取り下げ、建設計画は宙に浮いていた。東京電力福島第1原発事故後、世界の主要国で新設計画が一時中断したが、2011年12月にリトアニアのエネルギー省と日立は改良型沸騰水型軽水炉を建設する契約に仮調印した。2020年の稼働を予定し、他のバルト三国にも出資を呼びかけるとしている。2012年6月21日の議会承認を受け、リトアニア政府は引き続き地域のパートナーや日立とプロジェクト会社の設立や出資契約について協議する。投資に関する最終的な合意は2015年になる見込み。
ZIPファイルはファイルの最後に置かれるセントラルディレクトリの終端レコード（EOCD）の存在によって正しく認識される。この仕組みにより、新たなファイルを追加することが容易である。ZIPファイルに格納されているエントリ（ファイルまたはディレクトリ）数がゼロで無い場合、格納されている各エントリの名前、エントリに関するその他のメタデータ、ZIPファイル内でエントリデータが位置するオフセットが、セントラルディレクトリエントリに記載される。これにより、ファイルリストを参照するためにアーカイブ全体を読み込む必要がないため、アーカイブのファイルリストを比較的速く表示することが可能である。また冗長性の確保のため、各エントリも、エントリ情報をローカルファイルヘッダとして保持している。zipファイルが追加されることもあるため、ファイルの最後にあるセントラルディレクトリに載っているファイルだけが、正しいファイルである。セントラルディレクトリが、いくつかのファイルは削除された、あるい更新された、と宣言していることもありうるため、ZIPファイル全体を検索してローカルファイルヘッダを探しても、正しい情報は得られない（ただし、アーカイブが破損している場合は、そのような探索は役に立つだろう）。セントラルディレクトリ内でのファイルエントリの順番は、アーカイブの中での実際のファイルエントリの順番と同じである必要はない。ZIPファイル内のそれぞれのエントリは、ローカルファイルヘッダ（コメント、ファイルサイズやファイル名などの情報を含む）と、オプションの 「拡張」 データフィールドと、ファイルデータそのもの（圧縮されたり暗号化されている場合もある）で構成されている。「拡張」フィールドは、ZIP64フォーマット、WinZip互換のAES暗号化、ファイル属性やより詳細なNTFSやUnixファイルのタイムスタンプをサポートするために使用される。その他にも「拡張」フィールドを使用して機能拡張することが可能。認識しない拡張フィールドを無視するための機能をZIPツールに組み込む必要がある。ZIPフォーマットはファイル内の様々な構造を表すために、特定の4バイトの「シグネチャ」を使用する。それぞれのファイルエントリは、ある特定のシグネチャによって目印が付けられる。セントラルディレクトリの終端レコードは、それ用のシグネチャでマークされ、セントラルディレクトリ内の各エントリは別の特定の4バイトシグネチャによって目印が付けられる。ZIPの仕様にはBOFもしくはEOFといった目印がない。慣例として、ZIPファイルの最初にはZIPエントリが置かれ、そのシグネチャによって簡単にそれとわかる。しかし、ZIPの仕様においては、ZIPエントリで始まる必要はなく、特に、自己解凍型のアーカイブは、実行可能なファイルヘッダで始まる。ZIPアーカイブを正しく読み込むには、まず初めにセントラルディレクトリの終端レコードのシグネチャを探し、次に、適宜、他のセントラルレコードを探索する必要がある。ファイルチャンクが開始する場所を特定するのはセントラルディレクトリのみであるため、ZIPファイルの頭からエントリを検査すべきではない。ZIPフォーマットは、チャンク間に他のデータを含めることや、シグネチャと同じ4バイト列を含むようなデータを禁止していないため、そのようなスキャンは誤検出（フォールス・ポジティブ）を起こすだろう。  ただし、破損したZIPアーカイブからデータを修復するためのツールは、ローカルヘッダシグネチャを探索するのが普通である。この場合、ファイルチャンクの後ろにファイルチャンクの圧縮サイズが格納されることが、シーケンシャルな処理を困難にしている。また ZIPの仕様では、複数のファイルシステムにまたがって分散したアーカイブを扱うこともサポートしている。もともとは、複数の1.44MBフロッピーディスク にまたがった大きなzipファイルの格納を目的としていた。現在この機能は、ZIPアーカイブを分割してメールなどで送ったり、リムーバブルメディアで持ち運ぶのに使用されている。DOSのFATファイルシステムは2秒単位でタイムスタンプを保持し、ZIPファイルレコードはこれを模倣している。結果として、ZIPアーカイブ内にあるファイルのタイムスタンプも2秒単位で丸められる。但し、より正確なタイムスタンプを格納するために拡張フィールドを使用することができる。なお、ZIPフォーマットにはタイムゾーンという概念がないため、タイムスタンプが意味を持つのは、作成されたタイムゾーンを知っている場合だけである。2007年9月にPKZIPは、UTF-8のファイル名を格納するための仕組みを含むZIP仕様のリビジョンをリリースした。それは最終的にZIPに対するユニコード互換を追加するものである。