You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While debugging an issue with zips containing symlinks I noticed a couple of things:
The behavior of mz_zip_writer_add_file and mz_zip_writer_add_path is inconsistent. The latter skips symlinks if store_links and follow_links are false while the former does not. This makes mz_zip_writer_add_file effectively behave like if follow_links were true.
Attributes are always determined with lstat regardless of follow_links. If follow_links is true, I would expect the writer to store the attributes of the symlink target. Currently, we get zip entries with the contents of the symlink target that also have the ISLINK attribute set. This causes errors when reading such zips, because the reader tries to create a symlink treating the file contents as target path.
If both store_links and follow_links are set, we get store_links behavior and follow_links is ignored.
The text was updated successfully, but these errors were encountered:
While debugging an issue with zips containing symlinks I noticed a couple of things:
mz_zip_writer_add_file
andmz_zip_writer_add_path
is inconsistent. The latter skips symlinks ifstore_links
andfollow_links
are false while the former does not. This makesmz_zip_writer_add_file
effectively behave like iffollow_links
were true.lstat
regardless offollow_links
. Iffollow_links
is true, I would expect the writer to store the attributes of the symlink target. Currently, we get zip entries with the contents of the symlink target that also have the ISLINK attribute set. This causes errors when reading such zips, because the reader tries to create a symlink treating the file contents as target path.store_links
andfollow_links
are set, we getstore_links
behavior andfollow_links
is ignored.The text was updated successfully, but these errors were encountered: