Re: svn doesn't cope well with read-only auth cache

Johan Corveleyn <jcorvel_at_gmail.com> writes:

> Not much interest it seems. Filed an issue, so this doesn't get forgotten:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4504
>
> I don't have the time nor expertise right now to work on this, but if
> someone else wants to have a go ... by all means.

Similar problem on Unix but without the 10 second delays. The delay
after the "Store password unencrypted" prompt is the WIN32 retry loop
invoked by svn_io_file_open() called from svn_config_write_auth_data().
What causes the delay before the "unencrypted" prompt?

A couple of things:

 - svn_config_write_auth_data() is writing directly to the target file
   rather than writing to a temporary file and renaming. Using the
   rename mechanism would probably solve this problem is some cases
   since our rename changes the permissions, however it would still fail
   if the entire auth dir were readonly.

 - svn_auth__simple_creds_cache_set() calls svn_config_write_auth_data()
   and it is clearing the write error rather than returning it and there
   is a comment questioning this behaviour:

      if (err)
        *saved = FALSE;

      /* ### return error? */
      svn_error_clear(err);

      return SVN_NO_ERROR;

   If we were to return the error it would generally cause the whole
   operation to abort even though correct credentials had been supplied.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*