Loading ...
Sorry, an error occurred while loading the content.

7292Re: Life after NSLU2?

Expand Messages
  • docbillnet
    Apr 2, 2008
      --- In nslu2-general@yahoogroups.com, "Rob Lockhart" <rlockhar@...> wrote:
      > On Tue, Apr 1, 2008 at 1:42 PM, docbillnet <yahoo@...> wrote:
      > > --- In nslu2-general@yahoogroups.com, "Rob Lockhart" <rlockhar@>
      > > The man page says the checksums are always computed to compare the
      > > transfered files. Since you used -n, there was no transfer, so there
      > > was no checksum. If it doesn't write the temp file, it has nothing to
      > > compute the checksum on.
      > >
      > I just tried it again, and with "touch -t 200804010026.00
      100MiB_file" on
      > both sides, with *different CRCs*, there was no transfer, even
      without the
      > "-n" switch. No temp file created, no checksum generated, as there
      was no
      > transfer.

      As predicted. Exactly what I said, the checksum is always computed
      for transfered files. I am glad you could validate that the manual
      page is correct.

      > is no pending transfer. I'm not sure what would be gained in
      > the CRC on a file during transfer, perhaps only to ensure that it
      > the destination file CRC when being created? Indeed, the man page is

      I am assuming that the same code is used to compute checksums while
      reading regardless if the file transfer is local or remote. The same
      code is also probably used to compute checksums when saving,
      regardless of transfer mode. I can see absolutely no advantage in
      computing a checksum as your read a file and a checksum as you write a
      file locally. If the checksum is changing in your memory blocks, then
      no amount of sanity checking will help... I can see the advantage
      across a socket or a pipe. TCP-IP packets only use a very small
      checksum (I think it is one byte). Which means if you have enough
      errors occur you are almost guaranteed that one of them will be
      received as valid data. When you consider people will use rsync to
      copy many terabytes of data, that means they would regularly corrupt
      files with even the rarest of network errors if not for the additional

    • Show all 18 messages in this topic