syncjammer-users Mailing List for SyncJammer

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi, Donald.

You're not being a pest at all. You're helping me realize that I need to do some cleanup work on
Syncjammer.

You're suggestion is a good one. In fact, in SourceJammer (which I originally wrote the
streamFileToFile() method for) I've already made a similar change. Actually, I made a more generic
method called inputStreamToOutputStream():

  public static void inputStreamToOutputStream(InputStream stmIn, OutputStream stmOut)
          throws IOException{

    byte[] buffer = null;
    int iBufferSize = BUFFER_SIZE;
    buffer = new byte[iBufferSize];

    boolean bKeepStreaming = true;
    while (bKeepStreaming){
      int iBytes = stmIn.read(buffer);
      if (iBytes == -1){
        bKeepStreaming = false;
      }
      else{
        if (iBytes < iBufferSize){
          bKeepStreaming = false;
        }
        stmOut.write(buffer, 0, iBytes);
      }//end else some bytes returned.
    }//end while
  }

This method is called by streamFileToFile(). Well, sort of . . .

  public static void oldStreamFileToFile(File source, File target)
          throws IOException{
    FileInputStream stmIn = new FileInputStream(source);
    FileOutputStream stmOut = new FileOutputStream(target);
    int iBufferSize = BUFFER_SIZE;

    inputStreamToOutputStream(stmIn, stmOut);

    stmIn.close();
    stmOut.close();
    target.setLastModified(source.lastModified());
  }

The method is actually called "oldStreamFileToFile()" because I was doing some experimentation to
figure out the most efficient way to copy files in Java. Here are the methods SourceJammer uses as
its standard now:

  public static void handlerStreamFileToFile(File source, File target)
        throws IOException{
    FileOutputStream stmOut = new FileOutputStream(target);
    try{
      handlerStreamFileToOutputStream(source, stmOut);
    }
    finally{
      stmOut.close();
    }
    target.setLastModified(source.lastModified());
  }

  public static void handlerStreamFileToOutputStream(File source, OutputStream target)
          throws IOException{
    FileDataSource dataSource = new FileDataSource(source);
    DataHandler handler = new DataHandler(dataSource);
    handler.writeTo(target);
  }

Of course this only works under Java 1.4 or later because it uses nio. Anyway, this is a little
bit faster and as you can see the code is much simpler.

Thanks for your positive comment about the readability of my code. I do strive for that, if I
don't always accomplish it.

Oh and your other question . . . No, SyncJammer does not delete remote files. I would not be that
difficult to change it so that it does this. I decided not to on the first pass as sort of a
safety feature--so that SyncJammer does not delete files that you end up wishing were still backed
up.

Thanks.

--Rob

--- "Holliday, Donald B. (LNG-CSP)" <Don...@le...> wrote:
> It appears that SyncJammer copies new and modified files to the destination,
> but does not delete files from the destination if they are deleted from the
> source.  Is that correct?
> 
> In jammer.filesys.FileSysUtil there is a method public static void
> streamFileToFile(File source, File target).
> The code is nicely written and easy to understand.  It is:
> 
> 	public static void streamFileToFile(File source, File target)
> 	          throws IOException{
> 	    FileInputStream stmIn = new FileInputStream(source);
> 	    FileOutputStream stmOut = new FileOutputStream(target);
> 	    int iBufferSize = BUFFER_SIZE;
> 
> 	    boolean bKeepReading = true;
> 	    byte[] buffer = null;
> 	    while(bKeepReading){
> 	        buffer = new byte[iBufferSize];
> 	        int iNumRead = stmIn.read(buffer);
> 	        if (iNumRead == -1){
> 	            bKeepReading = false;
> 	        }
> 	        else{
> 	            stmOut.write(buffer);
> 	            if (iNumRead < iBufferSize){
> 	               bKeepReading = false;
> 	            }
> 	        }
> 	    }
> 	    stmIn.close();
> 	    stmIn.close();
> 	}
> 
> I noticed that variables "iNumRead" and "buffer" is allocated inside the
> while loop.  BUFFER_SIZE = 1024.  This means that an additional 1K of memory
> plus the size of an int is allocated on every trip through the while loop.
> Is there a reason that these variables have to be reallocated inside the
> loop, or could it have been allocated one time outside the loop and reused.
> I know this approach guarantees a clean buffer every time the read statement
> fills it, but looks to be expensive when copying large directory structures
> (I just copied over 7000 files in 4.5 hours).
> 
> Perhaps something like:
> 
> 	    boolean bKeepReading = true;
> 	    byte[] buffer = new byte[iBufferSize];
> 	    int iNumRead = 0;
> 	    while(bKeepReading){
> 	        iNumRead = stmIn.read(buffer);
> 	        if (iNumRead == -1){
> 	            bKeepReading = false;
> 	        }
> 	        else{
> 	            stmOut.write(buffer, 0, iNumRead);
> 	            if (iNumRead < iBufferSize){
> 	               bKeepReading = false;
> 	            }
> 	        }
> 	    }
> 	    stmIn.close();
> 	    stmIn.close();
> 	}
> 
> This way no memory allocations are made inside a tightly wrapped loop that
> may have many iterations.  Of course, I haven't compiled and tested the
> modified code.  Just asking.
> 
> Also, it looks like stmIn.close(); is called twice, and stmOut.close(); is
> never called.  I assume this is a copy paste that didn't get updated (I do
> this on a regular basis.)
> 
> Sorry to be a pest, but I really like the tool and am trying to understand
> it better.
> 
> Thanks,
> 
> Donald Holliday
> (719) 481-7501            V
> Donald.Holliday@LexisNexis.com
> 

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec

syncjammer-users Mailing List for SyncJammer

syncjammer-users — Discussion of end-user related issues.