dmdz

[Walter Bright]

Andrei Alexandrescu wrote:
> Reading the file header (e.g. first 512 bytes) and then matching against 
> archive signatures is, I think, a very nice touch. (I was only thinking 
> of matching by file name.) There is a mild complication - you can't 
> close and reopen the archive, so you need to pass those 512 bytes to the 
> archiver along with the rest of the stream. This is because the stream 
> may not be rewindable, as is the case with pipes.

The reasons for reading the file to determine the archive type are:

1. Files sometimes lose their extensions when being transferred around. I 
sometimes have this problem when downloading files from the internet - Windows 
will store it without an extension.

2. Sometimes I have to remove the extension when sending a file via email, as 
stupid email readers block certain email messages based on file attachment 
extensions.

3. People don't always put the right extension onto the file.

4. Passing an archive of one type to a reader for another type causes the reader 
to crash (yes, I know, readers should be more robust that way, but reality is 
reality).


Is it really necessary to support streaming archives? The reason I ask is we can 
nicely separate building/reading archives from file I/O. The archives can be 
entirely done in memory. Perhaps if an archive is being streamed, the program 
can simply accumulate it all in memory, then call the archive library functions.