-
Notifications
You must be signed in to change notification settings - Fork 34
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
New tar gz #146
New tar gz #146
Conversation
…which will produce an other GADT value and Tar_{,lwt_}unix which evaluate our GADT
We can list .tar.gz archives that consists of directories and empty files \o/ files with content is not possible /o\
The position is not always possible to keep track of, and is not very useful to begin with. The documentation better explains the lightweight higher kinded types trick. Co-authored-by: Calascibetta Romain <[email protected]> Co-authored-by: Reynir Björnsson <[email protected]>
Co-authored-by: Calascibetta Romain <[email protected]> Co-authored-by: Reynir Björnsson <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I mostly have minor comments. We should document better the new additions.
The new Tar.Write
could be used in Tar_unix.create
and Tar_unix.append_file
.
I did not review closely the gzip details as I am not too familiar with the gz code and I suspect you on the other hand is intimately familiar with it :D
(** [out hdr entries] is a [_ t] that writes [entries] into an archive. [hdr] is | ||
the global header and each entry must come from a {!type:content} stream and | ||
the associated header.*) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add that it is the responsibility of the caller to ensure the file size of the header corresponds to the content.
I also wonder if this interface makes it difficult to recover from an error.
dispenser () | ||
| `Active fd' -> | ||
match Unix.read fd' buf 0 (Bytes.length buf) with | ||
| 0 | exception End_of_file -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think Unix.read
raises End_of_file
(but it doesn't hurt to catch...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, the End_of_file
comes from Stdlib.input
. Feel free to delete it.
Co-authored-by: Reynir Björnsson <[email protected]>
The global header is now an optional Tar.Header.t. In otar we then can't use the "global header" for the directory entry (it's not a proper global header but just a regular directory header) - so we add it to the list of entries.
I think it's ready to merge 👍. All contributors agreed on this version, |
CHANGES: - Fix `Header.marshal` and the checksum and the length (@reynir, mirage/ocaml-tar#145) - Delete a mutable field about the level into the header (@hannesm, mirage/ocaml-tar#141) - **BREAKING**: de-functorize the package (@hannesm, @reynir, @dinosaure, mirage/ocaml-tar#140, mirage/ocaml-tar#143, mirage/ocaml-tar#146) These PRs attempt to de-functorize `Tar` so that users can implement I/O themselves, using `Tar`'s own element serialization/deserialization functions to take advantage of read/write methods. This avoids imposing on the user the implementation of a module that is too rigid in his/her case (which could have performance implications). `Tar` offers functions for serializing/deserializing tar-specific elements from `string`. It is then up to the user to know how to obtain or write these `strings`. To this, these PRs add "logics" (see `'a Tar.t`) requiring read and/or write implementations and describing how to extract all entries from a tar file or how to write a tar file according to a "dispenser" (like `Seq.to_dispenser`) of entries. These logics do not depend on a particular "scheduler", and these PRs propose a derivation of these logics with `tar-unix`, `tar-eio` and `tar-mirage`. These latter derivations mean that the API for these packages has only been extended, and there are no breaking changes as such. These logics also make it easy to offer a compression/decompression layer with `decompress`, so you can easily manipulate and/or create a .tar.gz file.
CHANGES: - Fix `Header.marshal` and the checksum and the length (@reynir, mirage/ocaml-tar#145) - Delete a mutable field about the level into the header (@hannesm, mirage/ocaml-tar#141) - **BREAKING**: de-functorize the package (@hannesm, @reynir, @dinosaure, mirage/ocaml-tar#140, mirage/ocaml-tar#143, mirage/ocaml-tar#146) These PRs attempt to de-functorize `Tar` so that users can implement I/O themselves, using `Tar`'s own element serialization/deserialization functions to take advantage of read/write methods. This avoids imposing on the user the implementation of a module that is too rigid in his/her case (which could have performance implications). `Tar` offers functions for serializing/deserializing tar-specific elements from `string`. It is then up to the user to know how to obtain or write these `strings`. To this, these PRs add "logics" (see `'a Tar.t`) requiring read and/or write implementations and describing how to extract all entries from a tar file or how to write a tar file according to a "dispenser" (like `Seq.to_dispenser`) of entries. These logics do not depend on a particular "scheduler", and these PRs propose a derivation of these logics with `tar-unix`, `tar-eio` and `tar-mirage`. These latter derivations mean that the API for these packages has only been extended, and there are no breaking changes as such. These logics also make it easy to offer a compression/decompression layer with `decompress`, so you can easily manipulate and/or create a .tar.gz file.
This PR is the continuity of #140 and #143. It adds the support to make a
*.tar.gz
archive. I extended the GADT and introduce theWrite
operation. Then, it just matters of composition between the('a, 'err, 't) Tar.t
and thedecompress
layer.