You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"jdrivesync handles synchronization very well. But, for some applications, a simple copy or move operation is what is required.
For example, my application is a Raspberry Pi based wildlife camera. The camera writes jpeg and mp4 files onto its SD card, and a cron job periodically uploads these files to Google Drive using jdrivesync. I would like to be able to delete the files from the SD card once they have been uploaded, to free up space on the SD card. However, if I do this, the next synchronization deletes the files from Google Drive.
I would like to suggest a "--no-delete" option, that would prevent jdrivesync from deleting files from the target that have been removed from the source. I believe this would be easy to implement, and would make jdrivesync a much more flexible tool."
M. Fisher via email
The text was updated successfully, but these errors were encountered:
The implementation for the report still has to be changed. This issue here also indicates that I should change it. I think I will have to rework that one a bit.
"jdrivesync handles synchronization very well. But, for some applications, a simple copy or move operation is what is required.
For example, my application is a Raspberry Pi based wildlife camera. The camera writes jpeg and mp4 files onto its SD card, and a cron job periodically uploads these files to Google Drive using jdrivesync. I would like to be able to delete the files from the SD card once they have been uploaded, to free up space on the SD card. However, if I do this, the next synchronization deletes the files from Google Drive.
I would like to suggest a "--no-delete" option, that would prevent jdrivesync from deleting files from the target that have been removed from the source. I believe this would be easy to implement, and would make jdrivesync a much more flexible tool."
M. Fisher via email
The text was updated successfully, but these errors were encountered: