Propagate Deletion ALL DATA LOST

edited January 2015 in Acrosync for Mac
Hello
I was using Propagate Deletion until yesterday.... Unfortunately I lost all my back-up; I can redo it so this is not a big issue in itself but there is no protection when Acrsync cannot read the source directory ! This is what happened

Basically my source was 
 /Users/xxx/Data/Perso
ssh, 22, propagate deletion checked, (nothing in sync only don't sync)
All the file got remotely deleted and 0 file was uploaded.

Then I checked the log error in the console and found that
kernel[0]: Sandbox: Acrosync(xxx) deny file-read-data /Users/xxx/Data/Perso

Looks like as Acrosync was denied for some unknown reasons access to the directory, it assumed it was empty and did propagate the deletion.
Where Acrosync cannot read it should not assume it is empty....
If this is the case, please  fix this issue as soon as possible.

I am running 1.5. I just looked at a similar post in November (deletion happened at restart/reboot for one user); I had the impression this kind of precaution was taken by Acrosync before deleting. But apparently in my case there was not any precaution/warning.

Thanks and Regards
philoouu

Comments

  • I just double checked that Acrosync always checks if the local directory is accessible before the sync, and it is a surprise that OS X can deny the access without returning an error from those sandbox-related functions.

    The solution here is to add a check to abort the upload if the local directory is empty and deletion propagation is on.  I'll do this tomorrow.
  • edited January 2015
    Thanks gchen for your immediate answer... Your support is great!
    Yes if you put the condition source directory empty and propagation deletion means Upload is aborted, it should be safe!
    You should do it for both download/upload with the condition on the source.

    I guess it will be updated automatically in the Apple Store tomorrow then.

    A few more requests since you are here, but those ones more ergonomically. Would it be possible 
    - to move the different profile so that the last created one is not always on the right side
    - to be able to give these profiles a name so that it is easier to recognise them (right now they take the name of the folder source)

    Thanks and Regards
    philoouu
  • Just submitted the update to the Mac App Store.  It may take up to 7 days for them to review so you won't be able to see it tomorrow.

    I'll try to get those 2 features into the next update.
  • Thanks gchen
    Will update it when it is available.
    Thanks for 2 others features.
    Regards
    philoouu
  • The new version with the fix finally passed the review and is now available in the Mac App Store.
Sign In or Register to comment.