"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?
> 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.
> 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.
--
Philip Martin
---------------------------------------------------------------------
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:03:13 2005