Support config set backup-dir new-dir

[mapleFU]

This fixes #1007

TODO:

• Implement set backup-dir
• Update backup_mu_ to make set dir more lightweight (may not complete in this patch)
• Testing setting backup with gocase

[mapleFU]

@git-hulk in current implementions, a config set backup-dir ... might blocked by a backup or a purge. And the backup_mu_ is moved to Config. And the backup_creating_time_ will not be changed if config is changed, so it's still a bit trickey.

If we don't want blocked by a backup, backup_mu_ should have less critical sections, like:

config_set():
  grab backup_mu_
  set config
  reset backup_creating_time_ if storage_ != nullptr

backup():
  grab backup_mu_
  test backup_flag:
    return if backup_flag is True
  set backup_flag
  get config
  release backup_mu_
  
  do backup
   
  grab backup_mu_
  unset backup_flag
  if failed:
    return
  if config->backup-dir changed:
    return
  set backup_creating_time_

purge():
  grab backup_mu_
  test backup_flag and backup_creating_time_:
    return if backup_flag is True or backup_creating_time_ is not too old
  set backup_flag
  get config
  release backup_mu_

  pruge files

  grab backup_mu_
  unset backup_flag

[PragmaTwice]

Hi @mapleFU, after a glance, I have two simple ideas:

1. Could we add a new seperate mutex for directory changing? e.g. backup_mu and backup_dir_mu.
2. If we use only one mutex backup_mu, could we use try_lock on the directory changing? e.g.

if(backup_mu.try_lock()) exchange ...
else report("backuping, cannot change...")

[mapleFU]

1. Could we add a new seperate mutex for directory changing? e.g. backup_mu and backup_dir_mu.

It's ok, and it can solve part of the problem, but the syntax for backup_creating_time_ may still need to be specified.

2. If we use only one mutex backup_mu, could we use try_lock on the directory changing? e.g.

if(backup_mu.try_lock()) exchange ...
else report("backuping, cannot change...")

Both ok for me, personally, I think using backup_dir_mu is better here, but when we increasing our changable variables, the state of our system would be chaos. Maybe report error is better here.

[tanruixiang]

LGTM. Thank you very much for your contribution.

[mapleFU]

@git-hulk @PragmaTwice @tanruixiang update some comments, and the patch is ready to be merged now.

[git-hulk]

Thanks all, merging...