Questions about TT's Zip Package?

MacDirID is only used to check if two paths are pointing to the same file. Comparing paths is not 100% safe due the possibility of symlinks in the path components. E.g, /var/ and /private/var/ point to the same folder, and to any files therein. Without the DirID, detecting that is not guaranteed by Xojo. For example:

dim f1 as FolderItem = GetFolderItem("/var/tmp/aa") // uses symlinks dim f2 as FolderItem = GetFolderItem("/private/var/tmp/aa") // symlink-free dim p1 as String = f1.NativePath dim p2 as String = f2.NativePath break

While this test shows that NativePath returns the symlink-free value of a symlink-using path, suggesting I could just compare the paths instead of MacDirIDs, the problem is that this is not documented, and everyone at Xojo keep telling us that we may not make such assumption only on empirical data (ever tried to get a confirmation that using “for each” on an array uses a predictable order?). So, I’m playing safe here by using the DirID that is safe by Apple’s specs. Change the code to using only the NativePath or URLPath at your own risk.

The MacType value is something that is stored - optionally - in Zip files. Hence, I cannot simply remove its use, no matter that it’s declared doomed by Xojo. Only if you decide you do not need MacBinary support in Zip files, you can remove the entire code of that deprecation warning bothers you.

The other deprecation warnings remain in my lib for now because I like to keep supporting older Real Studio versions.

BTW, Xojo 2014r1 does not show any more warnings when I use “Analyse Project” a second time without modifying the code. How do I reset that? RS 2012r2.1 doesn’t exhibit this weird behavior.


I have updated the Zip package to v3.3.4:

It has no functional changes but should deal with some of the mentioned warnings (MacType is still in there) and improves the documentation related to the dll placement and the use of the Einhugur plugin.

Thank you for the update :slight_smile: