Is it a good idea to backup a directory on a HFS+ filesystem by using the Finder's Compress function, and then copying the ZIP file to a FAT32 hard disc, or to Dropbox, etc? Or might that cause data corruption or data loss?
For example, if I compress my iTunes library, and symlinks are replaced by another copy of the file, that's a change in the semantics. If my hard disc crashes, and I restore a copy of the iTunes library from backup, iTunes may not work properly because of this. For example, changing the contents of one file won't affect the other. Deleting the file being pointed to means that you can no longer read the contents of that file via the symlink, which again is different if the symlink is replaced by a copy of that file. iTunes may crash given a corrupt library, or further corrupt the library, which means that the backup failed to serve its purpose.
Is it guaranteed that all valid directories compress to ZIP without errors, and expand to an identical copy of the original directory, without any loss of information or semantic changes? More specifically, do ZIP files support all HFS+ features?
- Symlinks
- Hard links (including to directories, which are supported on HFS+)
- Aliases
- Extended attributes
- Resource forks
- ACLs
- Unix permissions
- All valid path names in HFS+. In other words, does ZIP support all characters that are valid to use in a path name? Does ZIP support the longest path name you can create in HFS+, or is there a lower path length limit in the ZIP format?
- Is there a 4GB file size limit?
... and so on.
I'm concerned about the potential for silent changes, which cause silent data loss or corruption without me being aware of it until it's too late.
This is a question about the ZIP format, and also about the Finder's Compress command. Because even if the ZIP format supports something, if the Finder's implementation doesn't, it doesn't help.