> - you make an extra 512 byte block if a file ends exactly
  on a block boundary (like a zero byte file, for example)

I couldn't reproduce this, actually. Are you using the most recent copy of
the code? My initial push had that issue, but I think I fixed it in this
commit<https://github.com/int3/guile100/commit/f39f4fa3e4fac55ba42403f83a05416237fbe0ee>
.

> - For files archived from the current directory, you
  explicitly add the "." path to the archive.  Most other
  tar programs don't do that.

Yeah, that definitely was happening. I've fixed it now.

Cheers,
Jez


On Sat, May 4, 2013 at 10:47 PM, Mike Gran <spk121@yahoo.com> wrote:

> > From: Jez <jezreel@gmail.com>
>
>
> >I actually submitted a pull request for this challenge
> > earlier today: https://github.com/spk121/guile100/pull/1/files
>
> Great! You were the first entry to meet the spec.
>
>
> > Not as fully-featured as Mark's, though. I just did what was
> > spec'ed out, with the exception of moving the footer to the
> > end of the archive rather than having it at the end of each file.
>
> Yeah, sorry about that footer spec error.
>
>
> I found two possible corrections
> - you make an extra 512 byte block if a file ends exactly
>   on a block boundary (like a zero byte file, for example)
> - For files archived from the current directory, you
>   explicitly add the "." path to the archive.  Most other
>   tar programs don't do that.
>
> Not that speed was the point of this exercise, but, in
> creating an archive from 10000 6kB text files, this script was
> about 10x slower than GNU tar, and slightly slower than
> Mark's tar.
>
>
> -Mike
>
>