mv bestanden maar alleen die rsync heeft gekopieerd

[Jazco2nd]

Ubuntu 20.04.1, rsync, mv:

In een map worden af en toe nieuwe bestanden aangemaakt. We noemen deze map:
/docs

Een python script triggered rsync nadat wijzigingen in deze map zijn voltooid. Rsync zal nieuwe bestanden kopieren naar een backup locatie, dus alleen bestanden die daar nog niet bestaan:
/backup

Nu wil ik graag direct daarna een mv commando om de bestanden van /docs die door Rsync zijn gekopieerd te verplaatsen naar:
/docs/archive
(Deze map is excluded bij rsync.)

Maar stel dat rsync is getriggered en wel 10GB moet kopieren van /docs naar /backup. Dat duurt even.
Ondertussen kunnen nieuwe bestanden naar /docs worden geschreven.
Als rsync klaar is wordt direct het mv commando aangeroepen en alle bestanden, ook die nieuwe bestanden die dus nog niet zijn gebackupped door rsync, naar /docs/archive geschreven. Dat wil ik niet.. rsync zal vanzelf weer een keer worden aangeroepen en vervolgens zal het die bestanden dus niet meer zien om te backuppen.

Hoe kan ik dit specifieke geval voorkomen? Ik wil dus eigenlijk dat het mv commando alleen bestanden verplaatst die zojuist door rsync zijn herkent als "nieuw".


EDIT:
een simpele oplossing zou zijn om eerst het mv commando uit te voeren, nieuwe bestanden naar /docs/archive kopieren. Vervolgens vanuit die map rsyncen naar /backup. Dit vind ik heel aantrekkelijk.. maar wil ik juist niet, omdat een gebruiker ten allen tijde /docs/archive mag leegvegen (hij weet dat alles in die map is gebackupped). Zeker als het om grote bestanden gaat is de kans groot dat die map snel wordt leeggeveegd om ruimte te maken. Dan heeft rsync misschien nog geen kans gehad om alles te backuppen.

EDIT2:
ik besef dat de genoemde oplossing op zich wel kan. Voordat een gebruiker ziet dat de bestanden in /docs/archive zitten, is rsync denk ik wel klaar met backuppen.
De gebruiker kijkt namelijk zelden werkelijk naar /docs of /docs/archive, maar naar een (2-way) gesynchroniseerde versie daarvan op een remote locatie.
rsync en mv werken beide lokaal en zullen dus eerder klaar zijn dan de synchronisatie naar remote..

[ Voor 40% gewijzigd door Jazco2nd op 29-10-2020 16:41 ]

[Mijzelf]

Wat als je de bestanden naar /docs/temp/ moved, en vandaar uit rsync draait, en als je klaar bent alles naar /docs/archive/ ?

[thunder7]

Ken je inotifywait ?

daarme kun je acties uitvoeren in een bash script als de file een bepaalde bewerking ondergaat (bv. close_write, het afsluiten van een file na schrijven). Zo'n actie zou dan kunnen bestaan uit 'rsync blabla && mv blabla /docs/archive/'.

Of je moet de output van rsync opvangen, doorlopen en alleen die bestanden die rsync gekopieerd heeft naar archive/ verplaatsen.

[ Voor 20% gewijzigd door thunder7 op 29-10-2020 16:51 . Reden: typefout ]

[Jazco2nd]

@Mijzelf @thunder7
Wat ik heb weggelaten:

/docs wordt door Syncthing synchroon gehouden met een telefoon.
Het script gebruikt de REST API van Syncthing om te monitoren wanneer Syncthing klaar is met het synchroniseren van de gehele folder (event "FolderCompletion"). Dat vind ik in deze situatie handiger dan close_write, want dit script moet echt een verlenging zijn van Syncthing.

Ik wist niet dat je 2 acties in 1 commando kon uitvoeren (ik heb mezelf bash en beetje python scrypting aangeleerd middels overdreven veel trial&error).

Maar als ik je suggestie goed begrijp, is "&&" hier niet zozeer de truc, maar stel je voor om het juist op file niveau te bekijken, zodat je per file rsync en mv uitvoert.. Misschien moet ik dan een combi van mijn huidige monitoring gebruiken met close_write..

Ik zie nu dat SyncThing voor close_write iets vergelijkbaars heeft ipv FolderCompletion: ItemFinished. Ik zou dan het pad dat wordt meegegeven kunnen gebruiken voor een rsync && mv commando.. volgens mij lost dat het op

Dan krijg je wel veel meer losse acties die worden uitgevoerd.. maar dat moet het systeem vast wel aankunnen.


EDIT:
OK ik ben er bijna, ik ben geen Python expert, maar ben een bestaand python script met veel trial & error aan het omzetten naar iets wat werkt voor mij. Om te testen is de enige actie die nu wordt uitgevoerd: schrijven naar een logfile.
https://github.com/zilexa...aster/syncthing-backup.py

Enige wat ik nog moet toevoegen:
Regel 64:
Checken of error=null.
alleen als action=update en error=null, is het een succesvol event en mag de actie worden uitgevoerd (want zie hier).
Op regel 64 check ik al update, naar als ik hetzelfde doe voor error gaat het mis. Mogelijk bestaat die variabele niet als ie leeg is.

Als dat is gelukt kan ik rsync && mv toevoegen en is het klaar

[ Voor 36% gewijzigd door Jazco2nd op 29-10-2020 19:40 ]

[Mijzelf]

Als je het per file doet, waarom dan rsync gebruiken? cp doet het toch ook?

[Jazco2nd]

Mijzelf schreef op donderdag 29 oktober 2020 @ 19:16:
Als je het per file doet, waarom dan rsync gebruiken? cp doet het toch ook?

Ja idd, goed punt! Hooguit omdat rsync wat verificaties uitvoert?