POJO File Synchronizer with Deletion Tracking.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Ivan Olexyn b71b0cce49
Copy code from lankydan.
5 years ago
doc Move diagrams to /doc . 5 years ago
src/com/olexyn/ensync Copy code from lankydan. 5 years ago
.gitignore Cleanup. 5 years ago
README.md Changes... 5 years ago

README.md

Table of Contents

  1. About
  2. Package Contents
  3. Issues


About

Sync files across directories.



Package Contents

File Description
artifacts/SyncDirectory A directory that is registered to a SyncEntity.
artifacts/SyncEntity A collection of directories that are being syncronized.
shell/ Contains .sh files
Execute Issues sh commands.
Main Run from here.
Routines Contains higher level routines.
Tools Contains lower level tools that are used by other classes.


Issues

  • Have Map entries be remove, once file ops is performed.
  • Create a parallel Thread for each SyncEnity.
  • Add support for modification dates.
    • And thereby eventually support 10 out of 10 file operation types.
  • Reduce disk access.
  • Have some error handling. (i.e. if a web-directory is not available)
  • Create a UI.
  • Start the program at system start.
  • Track files that were modified during the loop.
    • currently writeStateFile just takes from find
    • this means any changes made during the loop will be written to the StateFile
    • and created files are tracked by comparing StateFile (=old state) and State (=new state).
    • because of this it will appear as if the file created while the loop was running was already there.
    • thus the creation of said file will not be replicated to the other directories.
    • to solve this writeStateFile should take the old State and manually add every operation that was performed by the loop (!= user created file while the loop was running).
    • however this will be done later . . maybe.
  • If file is deleted in DirA and DirB, then two delete commands will be issued.
    • They will both return errors and effectively do nothing.
    • However this is a dirty solution.
    • Fix this by checking if deleted file of DirA exists in DirB.listDeleted
    • To do so .listDeleted would need to be a field of Dir
    • And the .lists of every dir would need to be calculated before any deletion took place.
    • Check if the reduced reobustness is worth the prettier solution.
  • File is created in DirB
    • Sync creates the file in DirA
    • Sync creates the file in DirB
      • this means the file in DirB is overwritten with cp for no reason.
      • implement a check to prevent this.