Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing case in p:archive? #203

Open
xml-project opened this issue Aug 28, 2019 · 3 comments

Comments

@xml-project
Copy link
Contributor

commented Aug 28, 2019

Unless I overlooked something, there seems to be a missing case. The specs say on 'update':

  • Any entry in the manifest that does not exist in the ZIP file provided on the archive port is added.

  • For any entry that does exist in the ZIP file provided on the archive port, a timestamp compare is done. When the entry in the manifest is newer than the entry in the ZIP file provided on the archive port, it is replaced. Documents that are either specified in the manifest or come from the source port have no timestamp and will always cause a replace to be done.

Now image I run update on a zip containing entries, that are not mentioned in the (constructed) manifest? What do we say about them?

I suppose these entries should be copied to the archive appearing on port result, but should be moved to the end of the zip because the manifest imposes an order on the entries.

Right?

@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

Sounds ok to me. Bit of an edge case I suppose, so let's just do it this way and see what happens?

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Aug 28, 2019

I have no idea how efficiently ZIP deals with updates. I think I'd be inclined to say that the order of the files in the update case is implementation defined. From an implementation point of view, I'd prefer:

  1. To update-in-place for updates.
  2. To add new entries to the end of the zip.
  3. To leave entries not in the manifest wherever they happen to wind up.

Requiring the implementation to move all the entries not in the manifest to the end of the zip file sounds like it could involve a lot of I/O.

But I'm ok with whatever you think the right answer is :-)

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Aug 28, 2019

@ndw Yes, order makes it complicated and results in a lot I/O. But the specs say:

The p:archive step should strive to retain the order of the c:entry elements when constructing the archive. For instance, an e-book in EPUB format has a non-compressed entry that must be first in the archive. It should be possible to construct such an archive using p:archive.

(Hint: The 'should' in the last sentence is not in terminology).

I am pretty sure creating ePub is a requirement for some users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.