javanuben Skrevet 5. oktober 2011 Del Skrevet 5. oktober 2011 (endret) Hei, jeg er i startgropen på et prosjekt, veldig inspirert av Dropbox. Beskrivelse Programmet skal synkronisere filer mellom forskjellige datamaskiner, men i motsetning til Dropbox, skal filene/mappene kunne ligge hvor som helst, og ikke nødvendigvis samlet. Det er mulig det allerede finnes programmer som gjør dette ute på det store nettet, men jeg gjør dette like mye for programmeringen sin del, som for det ferdige produktet. Hovedsaklig er dette prosjektet for meg selv, men om jeg blir fornøyd med programmet, kan det tenkes at jeg legger det ut på nettet for hvem som helst til å laste ned. Prosjektnavn Jeg fant ut at jeg burde ha et navn på prosjektet, derfor har jeg valgt å (foreløpig) kalle det for 'The Sigma Project'. Gresk stor Sigma (Σ) brukes i matematikken som tegnet for sum. Dette gjenspeiler målet med programmet mitt. Nemlig å summere filer på flere datamaskiner og presentere de som en samlet sum. Fremgangsmåte Planen er å dele opp programmet i flere "deler": - En del skal utføre selve "jobben", altså overføre filer (både sende og motta). Denne delen skal kjøre i bakgrunnen (muligens med et tray-icon). - En del skal være et GUI hvor brukeren kan velge hvilke filer/mapper som skal synkroniseres, og med hvem det skal synkroniseres. Brukeren skal også her kunne velge hvor ofte filene skal synkroniseres. F.eks. hvert n'te minutt, hver gang datamaskinen slåes av/på, eller la brukeren sette i gang synkroniseringen selv. I tillegg trenger programmet et par filer: - En fil som lagrer innstillingene (oppdateringsintervall ol.). - En fil som lagrer stiene til mappene/filene som skal synkroniseres. - En fil som lagrer informasjon om når mappene/filene siste ble synkronisert. Slik at brukeren kan få en advarsel hvis en synkronisering vil overskrive en fil som har blitt endret siden forrige synkronisering. (Brukeren burde også få et valg om hva han vil gjøre. F.eks. overskriv likevel, eller endre navnet på en av filene og beholde begge.) (De to siste filene er slått sammen til en. Se post 3.) I første omgang skal programmet forholde seg til IP-adresser, da jeg ikke har tilgang til en server for øyeblikket. Men om jeg skal legge ut programmet på nettet, kommer jeg nok til å endre det slik at brukeren kan lage seg en brukerkonto, og når programmet starter sender det IP-adressen til servereren automatisk, slik at brukeren slipper å forholde seg til IP-adressen.Jeg kommer nok også til å lage en søk-funksjon som scanner IP-er på samme nettverk etter en hvis port. Slik at hvis PCene som skal synkroniseres er på samme nettverk, trenger ikke brukeren å forholde seg til IP-adressen. Tid Prosjektet har ingen tidsfrist, da jeg gjør det for min egen del, samtidig som jeg studerer. Tiden mellom oppdateringer (her og på programmet) kommer derfor til å variere veldig, etter hvor mye tid til overs jeg har. Funksjoner ø Synkronisere og "merge" fillistene. ø Synkronisere filene på fillista. o GUI eller skikkelig "console" for utføring av operasjoner. o Støtte for automatisk filsynkronisering. o GUI for instillinger. o Tray icon. Forklaring: o Planlagt ø Ferdig Veien videre Som dere ser har jeg skrevet to klasser (kildekoden ligger nederst i tråden) for å sende og motta filer. Første steg videre nå, er å få programmene til å synkronisere fillistene, slik at overføringen kan starte. Måten jeg har tenkt å løse dette på, er at når programmet starter, lytter det på en gitt port for å vente på kommunikasjon fra en annen PC. Når to programmer (på to forskjellige PCer) da er startet, vil begge lytte på samme port. Men når programmet "aktiveres" (prøver å synkronisere filer), vil det slutte å lytte på porten, og heller prøve å koble til den andre PCen på den porten. Slik unngår jeg problemer av typen "hvem gjør hva først". Etter at programmene er "koblet sammen", vil klienten (den som koblet til den andre) sende en kommando til den andre om hva den vil skal skje (F.eks. send fillisten). Kommentartråd http://www.diskusjon...owtopic=1381854 Github https://github.com/j...e-Sigma-Project Kode Code.zip cc.zip [Oppdatert: 8.10.11] Hvis noen synes at dette høres tungvindt ut, eller finner feil i koden min, tar jeg gjerne imot forslag og kommentarer (i kommentartråden). EDIT: La til link til kommentartråden EDIT2 (5.10.11): Oppdaterte TODO-listen. EDIT3 (6.10.11): Oppdaterte TODO-listen. EDIT4 (8.10.11): Oppdaterte TODO-listen og lastet opp nyeste kildekode. EDIT5 (8.10.11): La til link til github. EDIT6 (9.10.11): Endret prosjektnavnet. EDIT7 (10.10.11): Endret den gamle TODO-listen til en mer langsiktig liste (de kortsiktige oppgavene/målene kommer uansett i de nye postene). Dette er min første "arbeidslogg", så jeg prøver og feiler litt etter hvert. Håper dere holder ut litt "fram og tilbake", og (litt) rot EDIT8 (12.01.12): Oppdaterte funksjoner-listen (krysset ut to av de, og la til en ny). EDIT9 (17.01.12): La til et ekstra punkt i funksjoner-listen. Endret 17. januar 2012 av javanuben Lenke til kommentar
javanuben Skrevet 5. oktober 2011 Forfatter Del Skrevet 5. oktober 2011 Har nå fått lagd en funksjon som sender og mottar fillistene hvis brukeren manuelt ber om det. Dette skal selvfølgelig automatiseres, men foreløpig må brukeren velge om programmet skal lytte etter kommandoer fra en annen PC, eller om det skal ta imot kommandoer fra brukeren. Min neste oppgave blir nok å få disse oppgavene til å kjøre parallelt. I tillegg har jeg begynt på kodingen av hvordan programmet skal fordele de ulike oppgavene. Foreløpig kan, som nevnt, programmet bare lytte etter og utføre kommandoer fra andre PCer ELLER fra brukeren. Det foregår slik at når programmet mottar en ny kommando (uansett hvor den kommer fra), så opprettes en ny instans av Executor. Executor er en klasse som skal utføre de forskjellige kommandoene, derav navnet (execute). Denne klassen implementerer Runnable, slik at den blir startet i en egen tråd. Dermed kan programmet fortsatt motta kommandoer mens Executoren jobber. (For mer informasjon kan du jo se på kildekoden som ligger i slutten av posten ) Jeg har også (i kommentartråden) fått et forslag om å starte et prosjekt på github for dette. Det kommer jeg definitivt til å se på, og jeg kommer til å poste link her når jeg har fått satt meg inn i det. cc.zip Lenke til kommentar
javanuben Skrevet 6. oktober 2011 Forfatter Del Skrevet 6. oktober 2011 Har ikke fått gjort veldig mye i dag, men kan likevel komme med en liten oppdatering. Programmet kan ikke gjøre en eneste ting i dag, som det ikke kunne i går, men jeg har skrevet en del hjelpefunksjoner: - En metode som går igjennom alle filene i fillisten og oppdaterer lastModified-attributten. Denne blir automatisk kaldt før programmet sender fillisten, og før programmet "loader" fillisten. - Metoder som loader og lagrer fillistene. - En (ikke helt ferdig) metode som synkroniserer fillistene (etter at fillisten fra den andre PCen er mottatt) - Hjelpemetoder til den over, som (foreløpig) igjennom kommandolinjen ber brukeren om stier til nye filer fra den andre PCen. Jeg har også kommet fram til et utkast av hvordan jeg kan strukturere fillisten. Med denne måten trenger jeg kun en fil for all informasjon om filene. Struktur: file_list.txt: id|path|last synchronized|last modified Som den observante leser kanskje har lagt merke til har jeg ikke nevnt noe om det jeg pekte ut som neste oppgave i min forrige post. Dette er fordi at jeg, etter litt hodekløing, fant ut at det var like greit å vente med automatisering og parallellisering til jeg er sikker på at ting fungerer som de skal. Disse oppgavene er derfor utsatt litt. Det som har høyest prioritet nå, er å skrive ferdig reportConflictToUser-metoden, som skal spørre brukeren (foreløpig) igjennom kommandolinjen om hva som skal gjøres med konflikter (filer som har blitt oppdatert siden forrige synkronisering og som nå blir forsøkt overskrevet). Brukeren får da 3 valg: 1. Behold begge filene, men gi den "nye" et nytt navn. 2. Ikke gjør noe (ingen filer blir endret). 3. Skriv over filen. Når denne metoden kommer på plass, må følgende funksjoner testes: o Oppdater lastModified for alle filene på fillisten. o Les fillisten inn i minnet. o Sending av fillistene mellom flere programmer. o Synkronisering av fillistene (legge til nye filer fra den andre PCen, og behandle konflikter). En utfordring som jeg har grublet mye på i dag, er hvordan tilordning av nye id-er til filene skal foregå uten at det oppstår konflikter. Dette tar jeg veldig gjerne imot forslag til i kommentartråden. En ting som jeg kanskje burde skjerpe meg på er kommentering av koden. Så langt er det alt for få kommentarer i forhold til kode. Fy! Dette skal jeg prøve å endre på. Jeg har også opprettet et prosjekt på github, men det er ikke helt klart til å publiseres enda (jeg får til min forargelse ikke til å slette opplastede filer ). Jeg skal se litt mer på det i morgen, og få publisert en link til prosjektet her. Til da, kan de oppdaterte filene lastes ned nederst i innlegget. cc.zip Lenke til kommentar
javanuben Skrevet 8. oktober 2011 Forfatter Del Skrevet 8. oktober 2011 (endret) Jeg har lagt merke til at innleggene mine ikke har vært særlig strukturerte eller lesbare. Fra nå av skal jeg prøve å gjøre det litt bedre. Ting som er gjort: - Kommentert deler av koden. - Lagt til en funksjon i run-metoden til Executor (som blir utført før kommandoene blir identifiserte) som erstatter #IP med IP-adressen til PCen. - Ordnet en måte som gjør at to tråder kan hente input fra System.in (mer info under 'Problemer'). - Endret separeringstegnet i file_list.txt til '<' istedet for '|', da det gamle tegnet ga meg en del problemer (mer info under 'Problemer). - Endret måten brukeren kommuniserer med programmet på: Nå lytter programmet automatisk på Main.STANDARD_MESSAGE_PORT, mens brukeren manuelt må sette den andre PCens IP ved å bruke kommandoen set_ip (hvis ikke et annet program sender kommandoen først). - Endret en del tungvindte metoder. - Testet og fikset en del metoder. Oppdatert liste for testing av funksjoner (fra post 3): ø Oppdater lastModified for alle filene på fillisten. o Les fillisten inn i minnet. ø Sending av fillistene mellom flere programmer. o Synkronisering av fillistene (legge til nye filer fra den andre PCen, og behandle konflikter). Problemer: - Da jeg skulle teste requestPathsFromUser (som jeg trodde jeg var ferdig med), oppdaget jeg at selvsagt er det ikke bare å prøve å hente input fra System.in, når det allerede er en BufferedReader som står og venter på kommandoer fra brukeren. Dermed måtte jeg lese meg opp på Synchronized-blocks. Jeg har ikke tenkt å prøve å forklare noe særlig rundt det, da jeg ikke er veldig stødig på det selv, men jeg fikk nå metoden endelig til å fungere. (Jeg har dog enda ikke testet om main-metoden min som venter på kommandoer fra brukeren får tilbake "eierskapet" av readeren, men regner med at dette ikke skal by på store problemer.) - Først brukte jeg '|' til å separere forskjellige deler av linjer i file_list. Dette fungerte imidlertid relativt dårlig: Da jeg kjørte String sin split-metode med "|" som parameter, returnerte den et array med hvert tegn. Mulig dette er elementært, men nå har jeg i alle fall lært det. Bugs: ø Sliter med tomme linjer i fillisten. ø Sammenslåing av sti og filnavn i requestPathsFromUser er ikke helt bra. o FileElementene blir ikke lagret på separate linjer etter sync file_list (Feil ikke lokalisert). Nye ting som må gjøres: o Skrive reportConflictToUser. o Lage en funksjon som lar brukeren vise filinnhold i konsollen (ved bruk av print kommandoen eller lignende). o Teste om Main "får tilbake" reader, etter at requestPathsFromUser er ferdig (evt. fikse dette). o Finne en måte å tilordne nye id-er på Kode: cc.zip EDIT: Glemte å legge ved koden EDIT2: Fikset litt på layoutet for å få det til å passe bedre med første post. EDIT3: Fikset horribel linjedeling (må slutte å kladde postene i Notepad >.<) Endret 12. januar 2012 av javanuben Lenke til kommentar
javanuben Skrevet 10. oktober 2011 Forfatter Del Skrevet 10. oktober 2011 Mini-update: Fikset den siste bugen på bug-listen fra forrige innlegg. Kan ikke huske at det har vært nødvendig å kalle BufferedWriter sin newLine-metode for å få linjeskift før.. Burde det ikke holde med "\n"? Kommer i alle fall til å fortsette med synkroniseringen av fillistene i dag (kommer nok en større oppdatering i løpet av ettermidagen/kvelden). PS. Navneforslag til programmet mottas veldig gjerne i kommentartråden! Lenke til kommentar
javanuben Skrevet 10. oktober 2011 Forfatter Del Skrevet 10. oktober 2011 (endret) Jeg har vist vært litt sloppy med å si i hvilken klasse metodene jeg omtaler ligger i, men jeg skal angi det foran metodenavnet fra nå av. Ting som er gjort: - Fikset bug som gjorde at Executor.updateLastModified ikke tok hensyn til om filene på fillisten har blitt overført (prøver ikke lenger å sjekke når en fil sist ble endret hvis den ikke eksisterer. - Har skrevet Executor.reportConflictToUser. (Denne metoden spør brukeren hva som skal gjøres med "konflikter". Se innlegg 3.) - Endret navnet på Executor.synchronizeFile_lists til Executor.mergeFile_lists, slik at det bedre representerer hva som blir gjort, og slik at navnet kan brukes til en metode som 1. Oppdaterer lastModified. 2. Sender en "set_ip #IP"-kommando til den andre PCen. 3. Sender en kommando til den andre PCen som "linker" de sammen (setter riktig IP). 4. Mottar fillisten fra den andre PCen. 5. Merger fillistene. - Kommentert flere metoder. - Har skrevet den nye Executor.synchronizeFile_lists-metoden (se ovenfor). - Endret "send file_list"-kommandoen til å ta et booelan argument som bestemmer om metoden skal sende en "receive file_list"-commando til den andre PCen. - Fikset bug som gjorde at FileSender prøvde å sende filen selv om sending av filstørrelsen mislyktes. - Testet sending, og merging av fillisten: Det ser ut som det fungerer som det skal nå! - Nok en endring av fillisten: id<path<lastSynchronized<lastModified<lastModified2 hvor lastModified er på 'denne' PCen, mens lastModified2 er på den som programmet synkroniserer mot. lastModified2 vil bli oppdatert under mergeFile_lists, og brukes for å ikke synkronisere unødvendige filer (filer som ikke har blitt oppdatert siden siste synkronisering). - Skrevet en metode Executor.loadFilesToSynchronize. - Skrevet metodene Executor.synchronizeFiles og Executor.SendFile som sammen sender filene mellom to linkede programmer, når "sync files" blir kjørt. Bugs: o "#IP" i en kommando blir ikke riktig erstattet av maskinens IP-adresse for alle kommandoer. Nye ting som må gjøres: o Lag en "bedre" måte å drepe Executors på (hvordan gjøre dette med en som bare lytter på en port? La en annen Executor koble til porten som blir lyttet på, for å få Executoren til å "gå videre"?) o Fjerne unødvendig spamming av System.out. o Teste Executor.reportConflictToUser. o Behandle exceptions litt bedre (kast de videre til executoren, istedet for å behandle alle der de oppstår. o Forbedre Executor.synchronizeFiles og Executor.sendFile til å sende alle filene samlet, i stedet for å sende en og en. (Noe som innebærer at programmet må lete igjennom file_list for å finne id og path for hver fil.) o Skrive og legge ut (her og/eller på gihub) en liste over tilgjengelige kommandoer. Ellers hadde jeg blitt glad om noen etterlot seg en kommentar i kommentartråden. Enten du har noe konstruktivt eller ei, så er det gøy å høre hva folk mener Jeg kommer forresten ikke til å laste opp flere kodefiler (med mindre noen ber om det), da de ligger på github EDIT: Fikset den elendige linjedelingen Endret 13. januar 2012 av javanuben Lenke til kommentar
javanuben Skrevet 11. oktober 2011 Forfatter Del Skrevet 11. oktober 2011 Mini-update: Bugs (fra forrige innlegg): ø "#IP" i en kommando blir ikke riktig erstattet av maskinens IP-adresse for alle kommandoer. Løsning: Problemet var at jeg kalte Executor.sendText direkte fra en annen metode, uten å gå via Executor.run-metoden hvor faktisk innsettingen av IP-adressen skjer. Jeg har nå skrevet en metode Executor.insertIP som tar seg av jobben, og som blir kalt både i Executor.run og i starten på Executor.sendText. (github for kode ) Lenke til kommentar
javanuben Skrevet 13. oktober 2011 Forfatter Del Skrevet 13. oktober 2011 Mini-update: Har skrevet om koden i FileSender, etter at det ble påpekt (i kommentartråden) at det var en del duplisering av kode i både FIleSender og FileReceiver. Sistnevnte blir nok oppdatert i løpet av kvelden eller morgendagen. Ikke bare var det duplisering av kode mellom FileSender.sendFileSize og FileSender.sendFile, men førstnevnte metode var også nesten identisk med Executor.sendText. Har derfor skrevet om Executor.sendText til å returnere en boolean som forteller om sendingen var vellykket eller ikke, slik at FileSender.sendFileSize kunne erstattes med Executor.sendText. (github er oppdatert.) 1 Lenke til kommentar
javanuben Skrevet 19. oktober 2011 Forfatter Del Skrevet 19. oktober 2011 Mini-update: Det har skjedd lite med prosjektet på en stund nå, men endelig kommer det en liten oppdatering: Jeg har skrevet om FileReceiver for å unngå duplisering av kode. Den er fortsatt ikke perfekt, men det for holde for nå (gihub). En av grunnene til at det ikke har vært mer fremgang i det siste, er at jeg har testet programmet. Og det er spesielt en ting som irriterer meg: Når jeg kjører Executor.synchronizeFile_list (etter å ha satt riktig IP), så fungerer alt som det skal, helt til det blir sendt to meldinger (set_ip, og send file_list) til samme port, etter hverandre. I følge programmet som sender meldingene, fungerer alt greit, men hos programmet som skal motta meldingene ser det ut som at bare den første meldingen blir registrert. Dette mener jeg at fungerte før, men jeg kan ikke huske å ha endret noe som kan forårsake dette. Uansett er det dette problemet som har hovedprioritet nå, så inntil jeg får løst dette, kommer det til å være minimal fremdrift. Hvis noen ser hva problemet er, så tar jeg gjerne imot tips i kommentartråden Lenke til kommentar
javanuben Skrevet 1. november 2011 Forfatter Del Skrevet 1. november 2011 Prosjektet blir satt på pause til jeg får gjort unna noen eksamener Lenke til kommentar
javanuben Skrevet 12. januar 2012 Forfatter Del Skrevet 12. januar 2012 (endret) Nå har prosjektet vært i gang en liten stund igjen, og det er derfor på tide med en oppdatering. Ting som er lagt til/endret: Jeg har brukt mye tid på å teste og fikse på forskjellige metoder. Noen av de viktigste endringene er listet opp her: ø Fikset sånn at temp-mappen blir laget hvis den ikke eksisterer når Executor.ReceiveFile_list blir brukt. ø Endret Executor.synchronizeFile_lists til å sende en spesialkommando ('syncing'), istedet for å sende to kommandoer etter hverandre ('set_ip #IP' og 'send file_list false'). Synkroniseringen av fillistene skal derfor fungere som planlagt nå. ø Endret Executor.mergeFile_lists slik at det eneste den gjør er å legge til filer som mangler, og oppdatere lastModified2. ø Endret Executor.loadFiles til å finne ut hvilke filer programmet trenger å få tilsendt (ut fra lastModified og lastModified2), for så å "loade" filene. (Dette innebærer også å behandle konflikter.) ø Oppdaterte javadoc om endringene i Executor.mergeFile_lists og Executor.LoadFiles. ø Lagde en metode som genererer en tom filliste. ø Teste om Main "får tilbake" reader etter at Executoren er ferdig med å hente input (evt. fikse dette hvis det ikke fungerer) - Se under "Bugs som er fikset". ø Oppdater lastSynchronized når filer blir synkronisert. Bugs som er fikset: ø Fikset en bug i Executor.mergeFile_lists hvor lastModified og lastModified2 på "nye" filer ble byttet om. ø Fikset en bug som gjorde at lastModified2 ikke ble oppdatert som den skulle i Executor.mergeFile_lists. ø Main ser ikke ut til å få tilbake reader etter at en Executor har hentet input. Dette me fikses!! - Oppdatert: Feilen er at Executoren fortsatt står som waiter, selv om den har fått det den ventet på. - Oppdatert: Løst ved å endre fra get(0) til renmove(0) i Main.getNextUserInputWaiter. ø Ved 'sync files'/'load files' skal ikke programmet prøve å få tilsendt filer som ikke er på den andres filliste (og heller ikke filer som ikke trenger å bli oppdatert). (Fikset ved å sjekke om lastModified2 er lik 0.) Nå ser det ut til at programmet er i stand til å utføre kjerneoppgavene som planlagt (synkronisere fillistene og overføre de nødvendige filene). Deler av dette er dog relativt utestet, og derfor får testing høyeste prioritet nå. I tillegg har følgende oppgaver rimelig høy prioritet (oppsummert fra tidligere poster + nye oppgaver): Ting som må gjøres: o Lage en metode som lar brukeren vise innholdet i fillista i konsollen. o Finne en god måte for å tilordne id-er til nye filer på. o Lag en test på om vi får konflikter mellom id-er. o Lag en "bedre" måte å drepe Executors på. (Hvordan gjøre dette med en Executor som bare lytter på en port? -La en annen Executor koble til porten for å få Executoren til å "gå videre"?) o Fjerne/Fikse unødvendig spamming av System.out. o Behandle exceptions litt bedre (kast de videre til Executoren, istedet for å behandle alle der de oppstår). o Forbedre Executor.synchronizeFiles og Executor.sendFile til å sende flere filer samlet, istedet for å sende en og en (noe som innebærer at programmet må lete igjennom file_list for å finne id og path hver gang). o Undersøke (og eventuelt fikse) om programmet overskriver filer ved synkronisering av nye filer. o Lage en mulighet for å endre på fillisten. o La brukeren velge navn på fil, hvis han velger 'keep both' for en konflikt. o La programmet slette temp-mappen når programmet stoppes (evt. la bruker velge om den skal slettes eller ikke). Bugs: o Visning av IP blir ikke alltid riktig (f.eks. vises VirtualBox sin IP noen ganger). o Closingen av sockets i FileReceiver fungerer ikke som planlagt... (Har innført en midlertidig løsning ved å duplisere (fy!) litt kode for å stenge socketene, men en mer elegant løsning er ønskelig. (Et av problemene ved den gamle løsningen var at Socket-objekter av en eller annen grunn ikke ble gjenkjent som "closeable", selv om Socket implementerer java.io.Closable (kilde))) o Filer som ikke blir synkronisert forsvinner fra file_list når lastSynchronized oppdateres (Executor.synchronizeFiles). (Problemet er at fillisten blir skrevet over med de linjene som tilsvarer de filene som blir synkronisert. Løses enkelt ved heller å gå igjennom alle linjene i fillisten og oppdatere lastSynchronized for de filene som blir synkronisert, istedet for å overskrive hele filen.) o Ved valg av 'overwrite' ved en konflikt (i Executor.mergeFile_lists) blir ikke den gamle linjen i fillisten fjernet/endret. (Det blir bare lagt til en ny linje med den andre filen.) Ser forøvrig at "The Sigma Project"-navnet allerede er i bruk, men siden det bare er en arbeidstittel lar jeg den stå. Oppdateringene blir tilgjengelig på github i løpet av dagen! Sette stor pris på kommentarer. Både om prosjektet, koden og ikke minst om loggskrivingen min. Edit: Har nå fått oppdatert klassene på github, samt lastet opp en not-so-up-to-date liste over kommandoer (commands.txt). Denne kan brukes for de som av en eller annen grunn har lyst til å teste programmet. En kjørbar jar-fil kan lastes ned her: test-build-120112_3.zip (For problemer eller spørsmål, vennligst bruk kommentartråden. Kommer nok også til å skrive en kort guide om hvordan programmet kan brukes via cmd for de som synes at commands.txt ikke er nok.) Endret 12. januar 2012 av javanuben Lenke til kommentar
javanuben Skrevet 13. januar 2012 Forfatter Del Skrevet 13. januar 2012 Har nå testet og fikset, testet og tweaket, og testet og fikset litt mer. Jeg har lagt til en del ny funksjonalitet, og (skapt og) fikset en hel haug med bugs, men nå ser det ut til at synkroniseringen av filer fungerer (relativt) smertefritt. Jeg kommer dog til å fortsette testingen, samtidig som jeg jobber meg igjennom TODO-listen min, så får vi se om jeg snart drister meg over til GUI-utforming eller noen av de andre hovedpunktene (i førstepost) snart. Ting som er lagt til/endret: ø Executor.loadFilesToSynchronize kaller nå Executor.updateLastModified før den gjør noe annet (slik at man ikke trenger å gjøre dette manuelt). ø Flyttet konflikttesten over til en egen medlemsfunksjon: FileElement.isConflict ø Skriv en metode for å legge en fil til fillisten (Executor.addFileToFile_list). ø Finne en god måte for å tilordne id-er til nye filer på (Executor.getNewFileID). (Se nederst i posten for mer informasjon.) ø Skriv en metode som fjerner en gitt fil fra fillisten (Executor.removeFileFromFile_list). Fiksede bugs: ø Filer blir i blandt loadet (med Executor.loadFilesToSynchronize) uten at de egentlig skal det. ø Filer blir (feilaktig) loadet hvis de ble endret og synkronisert samtidig. ø Ved f.eks. Executor.synchronizeFiles og Executor.synchronizeFile_list terminerer ikke Executoren (eller metoden) selv om det skjer en feil når man prøver å connecte. ø Hvis man connecter feil (eller til null) for å synkronisere filene, telles filene som synkronisert, selv om de ikke er det. ø Ved valg av 'overwrite' ved en konflikt (i Executor.mergeFile_lists) blir ikke den gamle linjen i fillisten fjernet/endret. (Det blir bare lagt til en ny linje med den andre filen.) ø Filer som ikke blir synkronisert forsvinner fra file_list når lastSynchronized oppdateres (Executor.synchronizeFiles). (Problemet er at fillisten blir skrevet over med de linjene som tilsvarer de filene som blir synkronisert. Løses enkelt ved heller å gå igjennom alle linjene i fillisten og oppdatere lastSynchronized for de filene som blir synkronisert, istedet for å overskrive hele filen.) ø Visse linjer blir overskrevet i fillisten hvis fillisten merges flere ganger uten at filene blir synkronisert, og fillisten(e) inneholder nye filer. (Problemet var at jeg fjernet alle de nye filene fra fillisten i starten av Executor.mergeFile_list, for å løse id-konfliktene, men jeg glemte å legge de som ikke fikk ny id tilbake igjen.) TODO: o Være litt mer nøye på hvilke metoder som er static, og hvilke som ikke er det. o Håndtere feil i fillisten(e) o Lage en metode som lar brukeren vise innholdet i fillista i konsollen. o Lag en test på om vi får konflikter mellom id-er. o Lag en "bedre" måte å drepe Executors på. (Hvordan gjøre dette med en Executor som bare lytter på en port? -La en annen Executor koble til porten for å få Executoren til å "gå videre"?) o Fjerne/Fikse unødvendig spamming av System.out. o Behandle exceptions litt bedre (kast de videre til Executoren, istedet for å behandle alle der de oppstår). o Forbedre Executor.synchronizeFiles og Executor.sendFile til å sende flere filer samlet, istedet for å sende en og en (noe som innebærer at programmet må lete igjennom file_list for å finne id og path hver gang). o Undersøke (og eventuelt fikse) om programmet overskriver filer ved synkronisering av nye filer. o Lage en mulighet for å endre på fillisten. o La brukeren velge navn på fil, hvis han velger 'keep both' for en konflikt. o La programmet slette temp-mappen når programmet stoppes (evt. la bruker velge om den skal slettes eller ikke). o Legge til støtte for å ha forskjellige filnavn (på forskjellige PCer) for samme fil. o Lage en sjekk på om fila som skal sendes eksisterer i FileSender. o Legg til en help-kommando. Bugs: o Visning av IP blir ikke alltid riktig (f.eks. vises VirtualBox sin IP noen ganger). (Her trenger jeg hjelp! Forslag og hint mottas med takk i kommentartråden!) o Closingen av sockets i FileReceiver fungerer ikke som planlagt... (Har innført en midlertidig løsning ved å duplisere (fy!) litt kode for å stenge socketene, men en mer elegant løsning er ønskelig. (Et av problemene ved den gamle løsningen var at Socket-objekter av en eller annen grunn ikke ble gjenkjent som "closeable", selv om Socket implementerer java.io.Closable (kilde))) o lastModified2 kan bli oppdatert (satt > 0), selv om den ikke finnes på den andre PCen, og lastSynchronized er lik 0. (Sliter dog med å gjenskape hendelsen.) Hvordan blir fil-id-ene organisert? Hvis det er nye filer som skal bli synkronisert på bare én av PCene, er det rimelig rett frem, og filene blir bare tildelt neste ledige ID. Er det derimot nye filer på begge PCene, blir det nødvendigvis konflikter (siden begge bruker samme algoritme til å generere ny ID). Det som da skjer, er følgende: Når programmet mottar fillisten fra det andre programmet, blir de nye filene der kopiert direkte inn i fillisten. Deretter sjekkes det for ID-kollisjoner (dvs. at to filer har samme ID). Når slike kollisjoner oppdages, får filene fra den gjeldende PCen generert nye IDer, etter at fillisten med de nye mottatte filene er lagret, slik at de samme IDene ikke blir generert om igjen. Jeg legger også ved nyeste test build for de som vil teste programmet. Siden det foreløpig ikke er veldig rett fram å bruke programmet, poster jeg en liten "tutorial" i neste post (for å prøve å holde det ryddig). Nyeste versjon: test-build-130112_2.zip Github er som vanlig(?) oppdatert! Lenke til kommentar
javanuben Skrevet 13. januar 2012 Forfatter Del Skrevet 13. januar 2012 Hvordan teste programmet: 1. Lagre .jar-filen hvor som helst på de to maskinene som skal synkroniseres. 2. Start programmet i cmd med: java -jar [filnavn.jar] 3. Skriv følgende for å få generert en tom filliste: generate file_list 4. Legg så til filene du vil synkronisere på følgende måte: add_file [filnavn] (Ja, dette er forholdsvis tungvindt foreløpig, men det blir bedre når jeg får ordnet GUI.) 5. Når du er ferdig med å legge til alle filene, "linker" du de to PCene sammen ved å skrive følgende i et av programmene: set_ip [den andre PCens IP-adresse] 6. Skriv så følgende for å få synkronisert fillistene: sync file_list Følg så anvisningen på skjermen når du blir spurt om filstier til de nye filene osv. 7. Følgende kommando synkroniserer filene på fillisten(e): sync files 8. Sleng så igjen en kommentar i kommentartråden om hvordan det gikk! Merk: Hvis du gjorde 5-7 kun med den ene PCen, er det kun den som har fått den andre PCens filer. For å synkronisere begge, må du gjenta de samme stegene på den andre PCen (eller gjøre det via 'send_command ...' (se commands.txt på github for mer info)). Syntes du dette var tungvindt? Sleng igjen en kommentar i kommentartråden da vel! Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå