filesystem V3 : remove_all by remove_all_aux problem

[anonymous]

Hi everyone,

First of all, I want to thanks boost::filesystem contributors for their amazing work. I use it, and it makes me learn a lot about library design.

In the filesystem V3, I found the following issue.

when using

boost::uintmax_t remove_all(const path& p, system::error_code* ec=0);

like this :

remove_all("C:\\test_path_to_delete");

the C:\test_path_to_delete (and its descendent) is successfully deleted (as described in documentation)

but when I use it like this :

boost::system::error_code ec;
remove_all("C:\\test_path_to_delete", ec);

The directory (and it descendent) aren't removed at all.

I have investigated and, I found the following :

file: boost_1_44_0/libs/filesystem/v3/src/operation.cpp
function: boost::uintmax_t remove_all_aux(const path& p, fs::file_status sym_stat, error_code* ec);

boost::uintmax_t remove_all_aux(const path& p, fs::file_status
sym_stat, error_code* ec)
{
  boost::uintmax_t count = 1;

  if (!fs::is_symlink(sym_stat)// don't recurse symbolic links
    && fs::is_directory(sym_stat))
  {
    for (fs::directory_iterator itr(p);
          itr != end_dir_itr; ++itr)
    {
      fs::file_status tmp_sym_stat = fs::symlink_status(itr->path(), *ec);

HERE=>   if (ec != 0 && ec)
            return count;

      count += remove_all_aux(itr->path(), tmp_sym_stat, ec);
    }
   }

  remove_file_or_directory(p, sym_stat, ec);
  return count;
}

This function is called by remove_all.

Here, ec is passed by address.

When

remove_all("C:\\test_path_to_delete");

is called, &ec = 0 (default argument)

so the check if (ec != 0 && ec) will never hit.

But when called with

remove_all("C:\\test_path_to_delete", ec); 

ec is allocated and &ec != 0, the check if (ec != 0 && ec) is allways true, and the function returns at the first iteration.

I'm maybe wrong, but, isn't this what you meant to do?

if (ec != 0 && *ec)
  return count;

Thanks again.

[Beman Dawes]

Thanks for the report, but I think this is essentially a duplicate of #4799 which was fixed October, 5th. See changeset 65765.

--Beman