On Wed, 2005-01-12 at 12:01, Philip Martin wrote:
> "Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
>
> > I'll be coming through in a pass later today to turn most of the
> > apr_file_FOO calls into svn_io_file_FOO calls with a nice neat SVN_ERR
> > wrapper around it (which should clean up the code a good bit).
>
> One difference between apr_ and svn_io_ is that the apr functions
> accept paths in the system's native encoding while the svn functions
> accept paths in UTF-8 and converts to native before calling apr. Now,
> the locking paths are ASCII representations of MD5 sums are they not?
> Does that mean that the encoding is irrelevant?
Yes.
> > I modified the code to use write_entries_file, which I
> > modified to do an atomic write by using a temporary file. The only
> > problem with this is that since I had been just appending to the file,
> > I'm now rewriting it entirely--a performance hit, but I guess
> > something that we'll have to live with to deal with to prevent writing
> > half a hash to an entries file.
>
> Do you modify an file more than once during a single operation? If so
> then the WC code used to have a similar problem with the entries file.
> It's much less of a problem now, see notes/entries-caching for some of
> the gory details.
>
> >>> + if (strncmp (buf, "K ", 2) == 0) /* We have a lock file. */
> >>> + {
> >>> + svn_lock_t *lock;
> >>> + SVN_ERR (read_lock_from_hash_name (&lock, fs, child, fd,
> >>> pool));
> >>> +
> >>> + apr_hash_set (*locks, lock->path, APR_HASH_KEY_STRING,
> >>> lock);
> >>> + }
> >>> + else /* It's another entries file. Recurse. */
> >>> + get_locks_under_path (locks, fs, abs_path, fd, pool);
> >>
> >> SVN_ERR or svn_error_clear.
> >
> > Done.
> >
> >> You haven't closed fd.
> >
> > read_lock_from_abs_path closes it.
>
> And that is called by read_lock_from_hash_name? I think that the call
> to read_lock_from_hash_name warrents a comment about the closing of
> the file.
*nod* See below.
> > I could change the code so that I
> > (the caller) always close the fd, but I was worried that if an
> > svn_error_t was thrown before it returned to me, the file would never
> > get closed. Thoughts?
>
> The fallback is that the file will get closed automatically when the
> pool passed to the open call gets cleared/destroyed. That is usually
> sufficient for most errors.
In that case, I'll just have the caller close the fd--I prefer that.
Thanks,
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 19:29:54 2005