OSX Lion libz 解压文件结构发生变化
基本上,当我解压存储在 OSX Lion 上的文件时,我将 zip 文件名作为文件夹中的文件进行获取...
因此,解压 zipfile.zip 会得到文件夹“zipfile”,其中包含 3 个文件。
1. zipfile.zip
2. zipfile
->file1
->file2
->file3
但是
如果它是在 OSX Leopard 中创建/使用的,我会解压这 3 个文件,但不是在文件夹“zipfile”中,而是在与 zip 文件相同的目录中。
因此,父文件夹结构“应该”如下所示:
1. zipfile.zip
2. file1
3. file2
4. file3
将其解压缩到我的 xcode 项目中
在 OSX Lion 中,如果我复制(或创建)我的 file.zip,并使用 ZipArchive.mm通过调用
-(BOOL) UnzipOpenFile:(NSString*) zipFile
并检查日志
NSLog([NSString stringWithFormat:@"%d entries in the zip file",globalInfo.number_entry] );
:我得到“10” zip 文件中的条目。
如果我在 OSX Leopard 中执行相同操作,我会得到 zip 文件中的 6 个条目。
我不太确定“globalInfo.number_entry”是什么意思,文件属性?
为什么 OSX Lion 中处理 zip 文件的方式有所不同?基本上,这意味着我必须将我的项目复制到 Snow Leopard 机器上进行构建并使用从未在 OSX Lion 操作系统上运行过的 zipfile.zip,该系统以某种方式更改了属性,导致解压缩过程为改变,导致我的项目失败。
有人知道我在这里得到什么吗?如此小的变化却是一个大问题。
当我输出 zip 文件结构时,来自 Lion:
filename: zipfile/
filename: zipfile/.DS_Store
filename: __MACOSX/
filename: __MACOSX/zipfile/
filename: __MACOSX/zipfile/._.DS_Store
filename: zipfile/file1.db
filename: zipfile/file2.db
filename: __MACOSX/zipfile/._file2.db
filename: zipfile/suburbs.db
filename: __MACOSX/zipfile/._file3.db
以及来自 OSX Leopard
file1.db
file2.db
__MACOSX/
__MACOSX/._file2.db
file3.db
__MACOSX/._file3.db
Basically when I unzip a file that has been stored on OSX Lion, I get the zip file name as a folder with the files inside the foler...
So Unzipping zipfile.zip gives me the folder 'zipfile' with 3 files inside of it.
1. zipfile.zip
2. zipfile
->file1
->file2
->file3
BUT
If it has been created/used in OSX Leopard, I get the 3 files unzipped but not in the folder 'zipfile', rather in the same directory as the zip file.
So the parent folder structure 'should' looks like:
1. zipfile.zip
2. file1
3. file2
4. file3
In OSX Lion, if I copy(or create) my file.zip, and unzip it in my xcode project using ZipArchive.mm
by Calling
-(BOOL) UnzipOpenFile:(NSString*) zipFile
and check the Log for:
NSLog([NSString stringWithFormat:@"%d entries in the zip file",globalInfo.number_entry] );
I get '10 entries in the zip file.'
If I do the same in OSX Leopard I get, 6 entries in the zip file.
I'm not really sure what 'globalInfo.number_entry' is supposed to mean, file attributes?
Why is there a difference in the way the zip file is being treated in OSX Lion? Basically it means that I have to copy my project to a Snow Leopard machine to make a build and use a zipfile.zip that has never been on an OSX Lion Operating system which has altered the attributes in some way, causing the process of unzipping to change, causing my project to break.
Anyone know what I'm getting at here? Such a small change and yet a massive problem.
From Lion when I output the zip file structure I have:
filename: zipfile/
filename: zipfile/.DS_Store
filename: __MACOSX/
filename: __MACOSX/zipfile/
filename: __MACOSX/zipfile/._.DS_Store
filename: zipfile/file1.db
filename: zipfile/file2.db
filename: __MACOSX/zipfile/._file2.db
filename: zipfile/suburbs.db
filename: __MACOSX/zipfile/._file3.db
And from OSX Leopard
file1.db
file2.db
__MACOSX/
__MACOSX/._file2.db
file3.db
__MACOSX/._file3.db
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
总体而言,我猜您在这里获得了两个不同的 .zip 文件,而不是一个,并且它们的创建方式不同。
在其中之一上,您选择了三个文件,右键单击并选择“压缩 3 个项目”。
另一方面,您选择了一个文件夹,并选择了“压缩(文件夹名称)”。
每个条目的完整路径名都存储在zip文件目录中,并且不会神奇地消失。
如果您确实在两台机器上从完全相同的 zip 文件开始,那么我会获取一份真正的解压缩工具的副本(/usr/bin/ 中可能已经有一个)并使用 '/usr/bin/unzip - l zip file.zip' 命令查看存档内的内容,而不扩展它。
Big picture, I would guess that you have gotten TWO different .zip files here, not one, and they've been created differently.
On one, you have selected the three files, right-clicked and selected "Compress 3 items".
On the other, you have selected a folder, and selected "Compress (folder name)"
The full pathname of each entry is stored in the zip file directory, and it won't magically disappear.
If you really are starting from the exact same zip file on both machines, then I would grab a copy of a real unzip tool (there may already be one in /usr/bin/) and use the '/usr/bin/unzip -l zip file.zip' command to look at what is inside the archive, without expanding it.