Client callbacks for archive_write_open

[omgal...@gmail.com]

Hi all,

I'm working on a C++ program that uses libarchive and I'm currently writing a set of client callbacks for archive_write_open. The idea is to have something similar to archive_write_open_memory, but using an std::vector<char> which can grow dynamically when needed instead of having to allocate a fixed size buffer. However, when looking at the documentation for the archive_write_callback, I saw the following:

"For correct blocking, each call to the write callback function should translate into a single write(2) system call."

I believe this is an implementation-defined constraint, and it would be impossible to predict how my C++ code would behave in this case. I saw the code for archive_write_open_memory and I noticed that memory_write ends up doing a memcpy, which I don't know whether it translates to a single write call. How valid is this constraint?

[Tim Kientzle]

We should probably clarify that documentation.

"Correct blocking" is needed when writing to tape drives and certain other hardware devices that require each physical write have the exact same size.

Generally, this is a factor only when writing to "raw" or "block" devices:


Writing to memory does not need correct blocking.

Writing to a file on disk does not need correct blocking.


Writing to a raw hard disk (one that has not been formatted with a file system) sometimes requires correct blocking.

Writing to optical drives (CD/DVD writers) sometimes requires correct blocking.

Writing to a tape drive usually requires correct blocking.


Tim

> --
> You received this message because you are subscribed to the Google Groups "libarchive-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to libarchive-disc...@googlegroups.com.
> To post to this group, send email to libarchiv...@googlegroups.com.
> Visit this group at https://groups.google.com/group/libarchive-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Martin Galvan]

Yes, that clears it up. Thanks!