Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • dailybuild_linux-x64
  • dailybuild_win32
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

sbbs

  • Clone with SSH
  • Clone with HTTPS
  • Rob Swindell (on Windows 11)'s avatar
    Rob Swindell authored
    Looks like this feature (commit d661427e) never really worked correctly
    since it counted the files removed from each sub-dir and then stopped deleting
    when the count reached the number of files in the base directory. This was
    done to accommodate the 'keep' feature (part of previous commits).
    So make 'keep' check conditional on it being non-zero and just don't ever use
    a non-zero keep value with a recursive delete and we should be good! :-)
    
    This fixes issue #841
    5e025ef3
    History
    Name Last commit Last update