问题标签 [archive]

是否有一个简洁的归档库可以自动为您处理归档文件夹或目录？我正在使用 Jython，所以 Java 库也可以使用。-UPDATE- 我也在寻找时间戳归档。IE

存档目录/2008/11/16/zipfilebypreference.zip

然后第二天再次调用它，它会创建另一个文件夹。我确定互联网上有一些东西，谁知道？

如何在 Java 中提取 tar（或 tar.gz 或 tar.bz2）文件？

所以我有一个客户，他的当前主机不允许我通过 exec()/passthru()/ect 使用 tar，我需要定期以编程方式备份​​站点，所以有解决方案吗？

这是一个linux服务器。

我有一个要归档的 MySQL 数据库。做这个的最好方式是什么？

注意：我不想只做一个备份。我想以一种我可以在以后获得的方式一次性导出数据以进行长期存储。特别是，我不想被绑定到 MySQL、数据库或任何给定的软件（我真的希望编写一个可以重新读取它的程序，比如几十行 C 或 perl） .

我目前的计划是使用 CSV 引擎将内容转储到表中，然后将其刻录到 DVD。这很好，因为 CSV 可以被许多不同的程序加载。唯一的问题是大部分数据都在 Blob 列中，就像二进制一样，所以我需要解码它是如何编码的。

我很想有一个实用程序来保存和恢复我当前的桌面状态，就像 Firefox 中的会话一样。充其量，它会冻结每个应用程序的状态、打开的窗口位置等，并提供一个可编写脚本的界面来随时恢复它们，就像你离开它们一样。

更现实地说，我可以列出打开了哪些应用程序、隐藏/最小化它们、从 Dock 中隐藏它们等，以便恢复它们（如果它们仍然打开）似乎会恢复它们 - 这样它就会很难不小心关闭它们。

最起码，我可以为每个保存的会话向 Leopard Spaces 添加一个新的桌面表面，并将所有内容移到那里，使用 Spaces 本身作为一种堆栈。

用例是：

1. 我开始做一些事情——比如说，这个问题——所以我在 Firefox 中打开了 stackoverflow，我启动了 XCode 和 ScriptDebugger，我写了几行代码，然后意识到我被困住了，直到我找到答案
2. 我将“继续使用 SessionSaver”日历事件添加到 iCal，或将任务添加到 OmniFocus
3. 我保存当前会话
4. 我将 AppleScript 附加到 iCal 事件或 OmniFocus 任务，它将重新打开我在步骤 3 中保存的会话

我在 Carbon 中看到了一些关于归档窗口层次结构的内容，但我希望它能够在 Snow Leopard 中的 64 位 Cocoa 中工作。（我目前在 Mac Pro 上使用 10.5.6。）

FinderWindowManager对 Finder 窗口执行类似的操作。

这类似于上一个问题，但那里的答案不能满足我的需求，我的问题略有不同：

我目前对一些包含排序数据的非常大的文件使用 gzip 压缩。当文件未压缩时，二进制搜索是一种方便且有效的方式来支持在已排序数据中查找某个位置。

但是当文件被压缩时，事情就变得棘手了。我最近发现了zlib的Z_FULL_FLUSH选项，它可以在压缩期间用于在压缩输出中插入“同步点”（inflateSync()然后可以开始从文件中的各个点读取）。没关系，尽管我已经拥有的文件必须重新压缩才能添加此功能（奇怪gzip的是没有此选项，但如果必须，我愿意编写自己的压缩程序）。

从一个来源看来，这甚至Z_FULL_FLUSH不是一个完美的解决方案......不仅不是所有 gzip 档案都支持它，而且检测档案中的同步点的想法可能会产生误报（与同步的幻数巧合）点，或者由于Z_SYNC_FLUSH也产生同步点但它们不能用于随机访问）。

有更好的解决方案吗？如果可能，我想避免使用用于索引的辅助文件，并且对准随机访问的显式默认支持会有所帮助（即使它是大粒度的——比如能够以每 10 MB 的间隔开始读取）。是否有另一种压缩格式比 gzip 更支持随机读取？

编辑：正如我所提到的，我希望在压缩数据中进行二进制搜索。我不需要寻找特定的（未压缩的）位置——只需要在压缩文件中寻找一些粗粒度的位置。我只想支持“将数据从大约 50%（25%、12.5% 等）开始解压缩到此压缩文件中”之类的支持。

是否有用于在 php 中创建/提取 zip 文件的库？

ZipArchive 类工作不规律，这在 php.net 上有所提及：（对于我检查的每个函数）

ZipArchive::addEmptyDir（没有可用的版本信息，可能仅在 CVS 中）

我正在数据库中设计一个表，它将存储来自应用程序的日志条目。有几件事让我比平时更多地考虑这个设计。

• 然而，系统将在运行时使用这些日志条目来做出决定，因此它们需要相对快速地访问。
• 他们还有一个问题是他们会很多（我估计每月增加 1250 万）。
• 我最多不需要超过过去 30 到 45 天的时间来进行决策处理。
• 对于支持和法律问题，我需要将所有这些保留超过 45 天，可能至少 2 年。
• 表设计相当简单，所有简单类型（没有 blob 或任何东西），在可能的情况下将使用数据库引擎放入默认数据，最多一个外键。
• 如果有任何不同，数据库将是 Microsoft SQL Server 2005。

我在想的是让它们写入实时表/数据库，然后使用 ETL 解决方案将“旧”条目移动到存档表/数据库 - 它很大并且在较慢的硬件上。

我的问题是您是否知道数据库/表设计的任何提示、技巧或建议，以确保它尽可能好地工作？另外，如果您认为这是一个坏主意，请告诉我，您认为更好的主意是什么。

我有一个要归档的目录：

所以目录是1.4gb。但是，该文件要小得多：

只有897mb。它没有以任何方式压缩：

为什么 tar 文件比它的内容小？

我们目前每周收到数千个平面文件，我有一个系统可以运行这些文件并将它们导出为 PDF 格式供我们的人员处理和参考。

我目前将这些批量加载到数据库中，确保所有字段/格式都有效，导出它们，并在下次运行时截断表。

我想知道的是，每个人都认为存储可能 6 个月的批量加载纯文本数据最节省空间的方式是什么？

无论是以日常 SQL 备份的形式，还是压缩档案的形式，或其他形式，所以我总是能够重新加载旧数据以进行故障排除。

欢迎任何想法，我愿意接受任何建议。