On Wed, Apr 03, 2013 at 09:51:38AM -0400, C. Michael Pilato wrote: > On 04/03/2013 07:04 AM, Stefan Sperling wrote: > > - prevent control characters from entering filenames at the repos layer > > +0 (It's a bit overly conservative, probably, but at this layer of the API > I'm less grumpy about that fact.)
Well, the argument goes like this: Subversion cannot handle \n in filenames at many levels. It was found that the FSFS layer cannot handle it without repository corruption, and it was pointed out that e.g. the unidiff format and the Subversion dump file format have problems with \n in filenames, too. So preventing filenames with \n in Subversion in general seems to be a good thing to do. Since only FSFS currently rejects \n, BDB users are left unprotected from harmful effects of \n outside the filesystem layer unless we make the BDB layer reject such paths as well (which you don't agree with) or make the repos layer reject such paths (which it does as of r1461760 and which we should backport IMO). Next, others have pointed out that similar issues can be caused by other control characters (such as \r) on some platforms, and also that libsvn_client has always been rejecting paths which contain any control characters. Consistency is a good thing, and making Subversion servers forbid control characters in filenames outright addresses our concerns about \n as well. Does that make sense? FWIW, I'm unhappy with the fact that we keep pretending the FS API was somehow special while today, for all practical purposes, it is not. I agree with Ben that the FS API should be considered an integral part of Subversion and should mirror constraints we build into the system in a consistent way because that makes Subversion easier to maintain in the long run and might prevent some classes of security and data corruption issues (such as the one that started this thread). But I can live with the current solution and respect the goals the FS API designers envisioned, and which the FSFS design failed to deliver, as long as the repos layer ensures that none of our users will run into nasty problems with control characters in filenames in the future.
