I've been investigating the behavior of libsvn_fs_fs with very large
paths (issue #2508) and I'm on the way towards at least making it a
bit more reasonable. The first problem is that the limits are kind of
inconsistent, in one place we use a 1024 byte buffer reading lines
that may include paths, in another there's a 4096 byte buffer,
although it can't ever actually use all that data since lines need to
pass through the first buffer to get to the point where the second one
is used.
The other problem is that when you overreach one of these limits, you
get a weird error about not being able to read a line from a file, not
a nice error that says "hey, the path is too long", so it would be
nice if we could be more explicit about this stuff.
Personally, I think we should be maxing things out somewhere above a
reasonable PATH_MAX, so a hard limit of 4096 byte long paths seems
reasonable to me. With no limit at all we're stuck in situations
where clients can cause us to use arbitrary amounts of memory by
sending large paths, and that's not cool.
I've got a patch here (attached) that handles the first part of the
problem, defining the buffers we use to read lines in terms of the max
path length we want to support, plus the other stuff that goes on
those lines in addition to the paths. On top of that I'd like to add
some error checking that catches overly long paths before they hit
that point, but I'm not entirely sure where they should go. Off the
top of my head I'd say the make_dir, copy, and make_file entries in
the fs vtable need to include checks, but I don't know enough about
the FS APIs to know if those are the only places that need to check.
Feedback from someone with more FS experience would be most appreciated,
-garrett
[[[
Make the limits for path lengths in the fsfs filesystem backend explicit.
This is part of issue #2508.
* subversion/libsvn_fs_fs/fs_fs.c
(MAX_PATH_LEN): New define, for the maximum path length we can store.
(MAX_HEADERS_STR_LEN): New define, for the maximum number of bytes we
need to be able to read in one line when reading headers.
(read_header_block): Use MAX_HEADERS_STR_LEN.
(MAX_CHANGE_LINE_LEN): New define, for the maximum number of bytes we
need to be able to read in one line when reading changes from a rev.
(read_change): Use MAX_CHANGE_LINE_LEN.
(write_change_entry): Unrelated, fix indenting.
]]]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 23 01:48:46 2006