Opened 17 years ago
Closed 16 years ago
#206 closed defect (fixed)
bitten linkify of log files breaks pysvn with is_canonical failure
Reported by: | atani@… | Owned by: | dfraser |
---|---|---|---|
Priority: | blocker | Milestone: | 0.6 |
Component: | General | Version: | dev |
Keywords: | Cc: | ||
Operating System: | Linux |
Description (last modified by dfraser)
from the Apache error_log:
[Wed Nov 07 02:01:14 2007] [notice] child pid 5478 exit signal Aborted (6) [Wed Nov 07 02:02:40 2007] [notice] SIGHUP received. Attempting to restart [Wed Nov 07 02:02:40 2007] [notice] Digest: generating secret for digest authentication ... [Wed Nov 07 02:02:40 2007] [notice] Digest: done [Wed Nov 07 02:02:41 2007] [notice] mod_python: Creating 8 session mutexes based on 256 max processes and 0 max threads. [Wed Nov 07 02:02:41 2007] [notice] mod_python: using mutex_directory /tmp [Wed Nov 07 02:02:41 2007] [notice] Apache/2.2.4 (Unix) DAV/2 SVN/1.4.4 mod_python/3.3.1 Python/2.5.1 configured -- resuming normal operations httpd: subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical(component, clen)' failed.
web_ui.py needs to be modified to not do repos.get_node(...) for paths with a single "." in it. Such as:
A examples/Makefile U . Checked out revision 539.
examples/Makefile is fine, but the "." is not. Having this lone "." causes the is_canonical case to fail. Masking this case from being linkified in web_ui.py: SourceFileLinkFormatter._replace with logic like below resolves the problem:
for part in parts: self.log.info('linkifying %s (%s)', part, path) if part != '.': path = posixpath.join(path, part)
Attachments (1)
Change History (9)
comment:1 Changed 17 years ago by atani@…
comment:2 Changed 17 years ago by atani@…
try 3 for replacement logic:
for part in parts: self.log.info('linkifying %s (%s)', part, path) if part != '.': path = posixpath.join(path, part)
comment:3 Changed 16 years ago by anonymous
- Priority changed from minor to blocker
-> empty build page
same problem, same fix, apply his to svn please.
comment:4 Changed 16 years ago by dfraser
- Description modified (diff)
- Owner changed from cmlenz to dfraser
- Status changed from new to assigned
Cleaned up syntax in description
comment:5 Changed 16 years ago by dfraser
I'm struggling to see that it's a single "." causing the problem, since that wouldn't match the regular expression for _fileref_re: (?P<path>[\w.-]+(?:/[\w.-]+)+)(?P<line>(:\d+))?
I'm adding tests to the unittests in the mean time. I think putting a normpath in the right place would be a better fix than avoiding the "." (this normalizes paths like foo/. correctly), but it would help to have an actual example to test:
for part in parts: path = posixpath.normpath(posixpath.join(path, part))
Could you submit an example of a log file that causes this problem?
comment:6 Changed 16 years ago by dfraser
r601 should fix this
comment:7 Changed 16 years ago by dfraser
Sorry, r602 should fix this :-)
comment:8 Changed 16 years ago by dfraser
- Resolution set to fixed
- Status changed from assigned to closed
r602 did indeed fix this
that mangled it... trying again..
bad path example:
replacement logic in web_ui.py: