1 2 Previous Next 20 Replies Latest reply: Dec 3, 2007 3:11 PM by jschellSomeoneStoleMyAlias Go to original post RSS
      • 15. Re: two way Directory replicator in bit level
        796440
        jschell wrote:
        That kind of stuff happens when you read one byte at a time. Each time you call a read method, it basically amounts to one Hard drive access. A Hard drive access is really slow, 10-20 ms, (due to the mechanical parts in your HDD),
        Not on any modern OS at least not at the level high order language calls. The OS will buffer reads.

        So excluding perhaps some real time javas that will not happen.
        I'm fairly certain that there's still considerable I/O overhead to writing byte-by-byte vs. buffered, though I haven't actually tested it that I can recall.
        • 16. Re: two way Directory replicator in bit level
          jschellSomeoneStoleMyAlias
          I'm fairly certain that there's still considerable I/O overhead to writing byte-by-byte vs. buffered, though I haven't actually tested it that I can recall.
          Not sure what you are referring to though.

          For the post that I was referring to there is no way that the OS is hitting the physical drive for each byte. Matter of fact it can't really since HD always transfer via a buffer (at least on standard desktop type computers.)

          And then the OS buffers it further.

          But if you mean something like where one flushes to the hard drive after each byte write versus waiting for the buffer to fill, then yes. Or using a larger buffer on top of the OS one. Performance there isn't realized due to byte buffering though but rather because of the larger buffer and transfer differences.
          • 17. Re: two way Directory replicator in bit level
            jschellSomeoneStoleMyAlias
            For any decent hash, the probability of two different versions of a given file hashing to the same value is exeedingly tiny, so if it's for, say, a daily backup of something where losing a day is expensive but not crippling, it might be a fair tradeoff.
            Ok. But if it was me I would prefer to use a timestamp and size, both of which are really likely to change for a backup, and then transfer the file even if it was large.

            If there was really a lot of data (100s of gigs maybe?) and it really didn't matter if one got lost every once in a while then I might consider it. I am not sure I would classify a normal backup in that second category although maybe if you are backing up every user computer then maybe.
            • 18. Re: two way Directory replicator in bit level
              807603
              Yes I used a Reader on top of my inputStream, thanks for the code it worked perfectly with no corruptions, The DataInputStream and DataOutputStream seems to do the job, I have tried to input/output a virtual disk and did not corrupt, awesome


              About hashing, does it mean to use hash table or use what I have found which is known as MessageDigest Class that converts memory chunks into strings, for example the below link:

              http://www.anyexample.com/programming/java/java_simple_class_to_compute_md5_hash.xml
              that had MD5 hash,

              The question is, do I use the MessageDigest class or simply use a hash table, and when comparing what Class to use???


              Thanks
              • 19. Re: two way Directory replicator in bit level
                796440
                Ozie02 wrote:
                About hashing, does it mean to use hash table or use what I have found which is known as MessageDigest Class that converts memory chunks into strings, for example the below link:

                http://www.anyexample.com/programming/java/java_simple_class_to_compute_md5_hash.xml
                that had MD5 hash,
                Message digest.
                • 20. Re: two way Directory replicator in bit level
                  807603
                  Thanks for the code and the steps to get this done, Appreciate that.
                  1 2 Previous Next