Filenames with trailing newlines wreak havoc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Filenames with trailing newlines wreak havoc

Stefan Sperling
When a file with a trailing newline (ASCII 0x0a) has made its way into
the repository, there are various areas of the system that exhibit failure
modes. Failure modes I observed in one particular case are discussed below.

I intend to file separate issues for each failure mode to keep track of
them, rather than filing one giant issue for them all. Though perhaps
a meta-issue that depends on the other issues would be useful.

In the case observed there was a file, added in a revision rX, which had
a trailing newline in its name. The file was added along with its parent
directory (which was also new in rX) and alongside several other files
in the same directory which did not have trailing newlines in their names.

The server was running Subversion 1.7.8, but might have been running
an older release at the time when rX was committed.
All commands listed below were run with Subversion 1.7.8.

Immediately visible problems were:

svnadmin verify resulted in an error for the revision: 'svnadmin: E160013: File not found: ...')

svnsync failed to sync the revision ('svnsync: E160013: File not found: ...')

However, the directory at rX could be listed (with svn ls) and checked
out successfully.

During checkout, RA layers were behaving inconsistently.

Checkout via ra_svn and ra_local resulted in the expected filename
with \n (0x0a) as the last byte both in wc.db (local_relpath NODES
column) and on disk.

However, ra_neon (didn't try serf) checked the file out with a trailing
space (0x20) instead of a trailing newline. The filename was stored with
a trailing 0x20 in wc.db as well as on disk.

Examining the FSFS revision file [*] of rX showed that the filename was
stored with a newline as part of its parent directory's representation.

  [*] For those who didn't know, the FSFS revision file format is documented
      here: https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure

Let's call the parent directory 'A', and the file in question 'alpha\n'.
A file named 'alpha\n' added in r1 might appear like this in its parent
directory's representation (i.e. the rep of 'A'):
============
PLAIN
K 6
alpha

V 17
file 2-1.0.r1/122
============

However, the cpath: field within the file's own representation did not
contain the trailing newline.

Also, the file was listed in the changed-paths data section without
the trailing newline. Note that the FSFS format docs say "The changed-path
data is represented as a series of changed-path items, each consisting of
two lines." -- i.e. a trailing newline is considered to be part of revision
file data, rather than the filename.

Furthermore, several children of the newly-added-in rX 'A' directory
were missing from the changed-paths list in the revision file, for an
unkown reason.
More precisely, children listed after 'alpha\n' in the rep of A were
missing from the changed paths list. This was not detected by 'svnadmin
verify' (which, in my opinion, is a bug) but was detected by 'svnsync'
when a later revision rY referred to one of the missing children in
copyfrom information. It turned out that the slave server was missing
any children of A not listed in the changed-paths list in the rX
revision file on the master server. What kind of consistency checks
could prevent this from happening remains to be determined. Perhaps
'svnadmin verify' could cross-check the changed paths list with node-rev
IDs which appear in the revision's directory listings?

The revision rX could be fixed by removing the trailing newline from the
filename in the parent directory's representation, and adjusting the
rep's length and checksum information accordingly. About two dozen other
revisions had to be adjusted as well because they listed the file
'alpha\n' as part of the 'A' directory rep (which is of course written
out in its entirety whenever a revision changes some child of 'A').

Also, the changed-paths list of rX had to be extended to add the missing
newly added children of A. Other revisions had to be checked for similar
omissions in the changed-paths list.

How the filename entered the repository is not known with absolute
certainty. The current theory, based on discussion with the revision's
author, is that the file was checked in using Eclipse with SVNKit 1.6
and was not refused by the Subversion server at the time.

Attempting the reproduce this problem with a stock Subversion client
in a naive way fails because libsvn_client refuses to add such files
to version control in the first place:

subversion/svn/add-cmd.c:86: (apr_err=160005)
subversion/svn/util.c:621: (apr_err=160005)
subversion/libsvn_client/add.c:1031: (apr_err=160005)
subversion/libsvn_client/add.c:937: (apr_err=160005)
subversion/libsvn_client/add.c:320: (apr_err=160005)
subversion/libsvn_wc/adm_ops.c:1004: (apr_err=160005)
subversion/libsvn_wc/adm_ops.c:679: (apr_err=160005)
subversion/libsvn_subr/path.c:1231: (apr_err=160005)
svn: E160005: Invalid control character '0x0a' in path '/tmp/wc/alpha\012'

This error does not seem to be triggered by our test suite, which
is bad because it would have allowed the SVNKit developers to prevent
this problem from happening (they use our test suite to test their
Java-based implementation of Subversion). There is a tab_test() in
commit_tests.py, but that test only tries a tab, not a newline character.

We should add some C tests as well to verify API behaviour at the
client layer and at the repos layer.

Given the ripple effects of this problem in FSFS revision files I think
we should ensure that the Subversion server blocks such filenames from
entering the repository (any repository, FSFS and BDB). It seems FSFS format
changes would be required to support filenames with trailing newlines
properly, an effort which isn't worth the gain in my opinion.

And given the ripple effects seen in areas such as repository verification,
svnsync, and ra_neon, I don't think we can afford to call this a supported
use case until all components of the system have been fixed to handle
filenames with trailing newlines properly.

Comments and opinions are very welcome. I intend to make sure that this
problem cannot happen with future Subversion releases, and welcome any
input and help I can get.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-5
On Tue, Mar 26, 2013 at 02:36:15PM +0100, Stefan Sperling wrote:
> When a file with a trailing newline (ASCII 0x0a) has made its way into
> the repository, there are various areas of the system that exhibit failure
> modes. Failure modes I observed in one particular case are discussed below.

The one thing you didn't explicitly spell out in your mail: the API (svn_fs.h)
considers such filenames valid.  That is, the bug is that the various parts of
the system failed to DTRT with those filenames, rather than that they failed to
reject them.  (Though, as you say, rejecting them may be the practical answer.)
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ben Reser
In reply to this post by Stefan Sperling
On Tue, Mar 26, 2013 at 6:36 AM, Stefan Sperling <[hidden email]> wrote:
> We should add some C tests as well to verify API behaviour at the
> client layer and at the repos layer.
>
> Given the ripple effects of this problem in FSFS revision files I think
> we should ensure that the Subversion server blocks such filenames from
> entering the repository (any repository, FSFS and BDB). It seems FSFS format
> changes would be required to support filenames with trailing newlines
> properly, an effort which isn't worth the gain in my opinion.

+1, this is not an allowed use and is obviously a hole in our server
implementations.  I'd actually say this is a potential DoS since
committing such a file creates all sorts of havoc for clients and
admins after the fact.

I'd suggest that we make svnadmin verify check for this condition and
report it.  Then devise a fix procedure to remove or rename the file
in the repository.  This allows admins to resolve their repositories
from this problem in case there are other cases of this out in the
wild that we don't know about.

> And given the ripple effects seen in areas such as repository verification,
> svnsync, and ra_neon, I don't think we can afford to call this a supported
> use case until all components of the system have been fixed to handle
> filenames with trailing newlines properly.

It probably breaks other things like the dump format and diff.  Tons
of things assume newline has special meaning.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-2
Ben Reser wrote on Tue, Mar 26, 2013 at 09:06:56 -0700:

> On Tue, Mar 26, 2013 at 6:36 AM, Stefan Sperling <[hidden email]> wrote:
> > We should add some C tests as well to verify API behaviour at the
> > client layer and at the repos layer.
> >
> > Given the ripple effects of this problem in FSFS revision files I think
> > we should ensure that the Subversion server blocks such filenames from
> > entering the repository (any repository, FSFS and BDB). It seems FSFS format
> > changes would be required to support filenames with trailing newlines
> > properly, an effort which isn't worth the gain in my opinion.
>
> +1, this is not an allowed use and is obviously a hole in our server
> implementations.  I'd actually say this is a potential DoS since
> committing such a file creates all sorts of havoc for clients and
> admins after the fact.
>

I'd call it a DoS if you can commit such a file and can't later 'svn rm
URL' it.

> > And given the ripple effects seen in areas such as repository verification,
> > svnsync, and ra_neon, I don't think we can afford to call this a supported
> > use case until all components of the system have been fixed to handle
> > filenames with trailing newlines properly.
>
> It probably breaks other things like the dump format and diff.  Tons
> of things assume newline has special meaning.

Fortunately we could encode newlines the same way in FSFS revision
files, diff, and dumpfile headers.  (Just need a new service routine
(dare I say yet another svn_foo_canonicalize() function? :-)))

Or we could forbid newlines in pathnames.  The only problem with that is
that the 1.0 API promised they would work... but if no one uses that,
I'd be fine with calling it an erratum and disallowing it henceforth.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Stefan Sperling
On Tue, Mar 26, 2013 at 06:10:35PM +0200, Daniel Shahaf wrote:
> I'd call it a DoS if you can commit such a file and can't later 'svn rm
> URL' it.

You cannot 'svnsync' the repository anymore, even if you rm the URL.
So you can DoS a master/slave setup and force the slave to be
out-of-date with no way to catch up until the revision is obliterated
or repaired.

> Or we could forbid newlines in pathnames.  The only problem with that is
> that the 1.0 API promised they would work... but if no one uses that,
> I'd be fine with calling it an erratum and disallowing it henceforth.

I think we should disallow it. There are too many unforeseen side effects.
I'm not even sure if I've already seen all failure modes that can result
from this.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-2
Stefan Sperling wrote on Tue, Mar 26, 2013 at 17:27:00 +0100:
> On Tue, Mar 26, 2013 at 06:10:35PM +0200, Daniel Shahaf wrote:
> > I'd call it a DoS if you can commit such a file and can't later 'svn rm
> > URL' it.
>
> You cannot 'svnsync' the repository anymore, even if you rm the URL.
> So you can DoS a master/slave setup and force the slave to be
> out-of-date with no way to catch up until the revision is obliterated
> or repaired.

Fair enough.  Infra would be interested in a pre-commit hook script that
checks for control characters in filenames and aborts the transaction.

:-)
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Michael Pilato
In reply to this post by Daniel Shahaf-2
On 03/26/2013 12:10 PM, Daniel Shahaf wrote:
> Or we could forbid newlines in pathnames.  The only problem with that is
> that the 1.0 API promised they would work... but if no one uses that,
> I'd be fine with calling it an erratum and disallowing it henceforth.

I'm very much in the "let libsvn_fs do everything it can, and let
libsvn_repos enforce Subversion-specific requirements" camp.

Certainly, libsvn_repos should be disallowing newline-bearing paths.  We
weren't able to support these paths when our .svn/entries file was
plaintext, we've never been able to support them in our dump format (which
is a libsvn_repos construct), and so on.

I'm not so sure about libsvn_fs.  BDB should be able to handle them just
fine, but it sounds like FSFS can't.  Do we just make a post-facto
declaration that, going forward, we won't try to support these paths in the
FS layer?

--
C. Michael Pilato <[hidden email]>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Stefan Sperling
On Tue, Mar 26, 2013 at 12:40:56PM -0400, C. Michael Pilato wrote:

> On 03/26/2013 12:10 PM, Daniel Shahaf wrote:
> > Or we could forbid newlines in pathnames.  The only problem with that is
> > that the 1.0 API promised they would work... but if no one uses that,
> > I'd be fine with calling it an erratum and disallowing it henceforth.
>
> I'm very much in the "let libsvn_fs do everything it can, and let
> libsvn_repos enforce Subversion-specific requirements" camp.
>
> Certainly, libsvn_repos should be disallowing newline-bearing paths.  We
> weren't able to support these paths when our .svn/entries file was
> plaintext, we've never been able to support them in our dump format (which
> is a libsvn_repos construct), and so on.
>
> I'm not so sure about libsvn_fs.  BDB should be able to handle them just
> fine, but it sounds like FSFS can't.  Do we just make a post-facto
> declaration that, going forward, we won't try to support these paths in the
> FS layer?

I don't really see how supporting such paths in the FS layer makes
sense if none of the other layers can deal with them.

Are there any other tools built on top of our FS layer that rely on
being able to use newlines in filenames?

But still, I was planning on making the repos layer enforce restrictions
on filenames anyway to avoid having each filesystem deal with it separately.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ivan Zhakov-2
In reply to this post by Michael Pilato
On Tue, Mar 26, 2013 at 8:40 PM, C. Michael Pilato <[hidden email]> wrote:

> On 03/26/2013 12:10 PM, Daniel Shahaf wrote:
>> Or we could forbid newlines in pathnames.  The only problem with that is
>> that the 1.0 API promised they would work... but if no one uses that,
>> I'd be fine with calling it an erratum and disallowing it henceforth.
>
> I'm very much in the "let libsvn_fs do everything it can, and let
> libsvn_repos enforce Subversion-specific requirements" camp.
>
> Certainly, libsvn_repos should be disallowing newline-bearing paths.  We
> weren't able to support these paths when our .svn/entries file was
> plaintext, we've never been able to support them in our dump format (which
> is a libsvn_repos construct), and so on.
>
> I'm not so sure about libsvn_fs.  BDB should be able to handle them just
> fine, but it sounds like FSFS can't.  Do we just make a post-facto
> declaration that, going forward, we won't try to support these paths in the
> FS layer?
>
We already have svn_fs__path_valid() and validate all incoming FS
paths in fs-loader.c. Current svn_fs__path_valid() implementation is:
[[[
svn_error_t *
svn_fs__path_valid(const char *path, apr_pool_t *pool)
{
  /* UTF-8 encoded string without NULs. */
  if (! svn_utf__cstring_is_valid(path))
    {
      return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
                               _("Path '%s' is not in UTF-8"), path);
    }

  /* No "." or ".." elements. */
  if (svn_path_is_backpath_present(path)
      || svn_path_is_dotpath_present(path))
    {
      return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
                               _("Path '%s' contains '.' or '..' element"),
                               path);
    }

  /* That's good enough. */
  return SVN_NO_ERROR;
}
]]]

Can we just extend it to prohibit all characters with ascii code < 31 ?


--
Ivan Zhakov
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ben Reser
In reply to this post by Daniel Shahaf-2
On Tue, Mar 26, 2013 at 9:29 AM, Daniel Shahaf <[hidden email]> wrote:
> Fair enough.  Infra would be interested in a pre-commit hook script that
> checks for control characters in filenames and aborts the transaction.

Use validate-files.py in the trunk tools/hook-scripts with a conf file like so:

[repositories]
* = newlines

# Running any rule against a file with a newline in it will fail
because we break the svnlook output by newlines.
# So the filename will appear as non-existent.  Hook will fail with an
error about the file not existing in the transaction and the commit
will fail.
# It's not pretty but it stops the problem.
[rule:newlines]
pattern = *
command = 'exit 0'
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ben Reser
In reply to this post by Ivan Zhakov-2
On Tue, Mar 26, 2013 at 10:57 AM, Ivan Zhakov <[hidden email]> wrote:

> We already have svn_fs__path_valid() and validate all incoming FS
> paths in fs-loader.c. Current svn_fs__path_valid() implementation is:
> [[[
> svn_error_t *
> svn_fs__path_valid(const char *path, apr_pool_t *pool)
> {
>   /* UTF-8 encoded string without NULs. */
>   if (! svn_utf__cstring_is_valid(path))
>     {
>       return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
>                                _("Path '%s' is not in UTF-8"), path);
>     }
>
>   /* No "." or ".." elements. */
>   if (svn_path_is_backpath_present(path)
>       || svn_path_is_dotpath_present(path))
>     {
>       return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
>                                _("Path '%s' contains '.' or '..' element"),
>                                path);
>     }
>
>   /* That's good enough. */
>   return SVN_NO_ERROR;
> }
> ]]]
>
> Can we just extend it to prohibit all characters with ascii code < 31 ?

Iterate the characters and use svn_ctype_iscntrl()
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-2
In reply to this post by Ben Reser
Ben Reser wrote on Tue, Mar 26, 2013 at 12:03:43 -0700:
> On Tue, Mar 26, 2013 at 9:29 AM, Daniel Shahaf <[hidden email]> wrote:
> > Fair enough.  Infra would be interested in a pre-commit hook script that
> > checks for control characters in filenames and aborts the transaction.
>
> Use validate-files.py in the trunk tools/hook-scripts with a conf file like so:
>

We've noted on IRC that this might fail if /foo and /foo\n get modified
in the same revision.

> [repositories]
> * = newlines
>
> # Running any rule against a file with a newline in it will fail
> because we break the svnlook output by newlines.
> # So the filename will appear as non-existent.  Hook will fail with an
> error about the file not existing in the transaction and the commit
> will fail.
> # It's not pretty but it stops the problem.
> [rule:newlines]
> pattern = *
> command = 'exit 0'
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ivan Zhakov-2
In reply to this post by Ben Reser
On Tue, Mar 26, 2013 at 11:07 PM, Ben Reser <[hidden email]> wrote:

> On Tue, Mar 26, 2013 at 10:57 AM, Ivan Zhakov <[hidden email]> wrote:
>> We already have svn_fs__path_valid() and validate all incoming FS
>> paths in fs-loader.c. Current svn_fs__path_valid() implementation is:
>> [[[
>> svn_error_t *
>> svn_fs__path_valid(const char *path, apr_pool_t *pool)
>> {
>>   /* UTF-8 encoded string without NULs. */
>>   if (! svn_utf__cstring_is_valid(path))
>>     {
>>       return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
>>                                _("Path '%s' is not in UTF-8"), path);
>>     }
>>
>>   /* No "." or ".." elements. */
>>   if (svn_path_is_backpath_present(path)
>>       || svn_path_is_dotpath_present(path))
>>     {
>>       return svn_error_createf(SVN_ERR_FS_PATH_SYNTAX, NULL,
>>                                _("Path '%s' contains '.' or '..' element"),
>>                                path);
>>     }
>>
>>   /* That's good enough. */
>>   return SVN_NO_ERROR;
>> }
>> ]]]
>>
>> Can we just extend it to prohibit all characters with ascii code < 31 ?
>
> Iterate the characters and use svn_ctype_iscntrl()
Yes, btw we already have such code in svn_path_check().


--
Ivan Zhakov
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-2
In reply to this post by Ivan Zhakov-2
Ivan Zhakov wrote on Tue, Mar 26, 2013 at 21:57:42 +0400:
> Can we just extend [FS validation] to prohibit all characters with ascii code < 31 ?

We can but that would break an API promise.  (A promise that we might be
fine with breaking.)
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ivan Zhakov-2
On Tue, Mar 26, 2013 at 11:48 PM, Daniel Shahaf <[hidden email]> wrote:
> Ivan Zhakov wrote on Tue, Mar 26, 2013 at 21:57:42 +0400:
>> Can we just extend [FS validation] to prohibit all characters with ascii code < 31 ?
>
> We can but that would break an API promise.  (A promise that we might be
> fine with breaking.)
I don't see API breakage here:
1. We already prohibited some FS paths (with . or ..)
2. Only new paths will be affected: users still can access already
created files/folders in repository.


--
Ivan Zhakov
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Daniel Shahaf-2
Ivan Zhakov wrote on Wed, Mar 27, 2013 at 00:13:12 +0400:

> On Tue, Mar 26, 2013 at 11:48 PM, Daniel Shahaf <[hidden email]> wrote:
> > Ivan Zhakov wrote on Tue, Mar 26, 2013 at 21:57:42 +0400:
> >> Can we just extend [FS validation] to prohibit all characters with ascii code < 31 ?
> >
> > We can but that would break an API promise.  (A promise that we might be
> > fine with breaking.)
> I don't see API breakage here:
> 1. We already prohibited some FS paths (with . or ..)
> 2. Only new paths will be affected: users still can access already
> created files/folders in repository.

svn_fs.h:1202
(I thought I'd given that pointer upthread)
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Ben Reser
In reply to this post by Ivan Zhakov-2
On Tue, Mar 26, 2013 at 1:13 PM, Ivan Zhakov <[hidden email]> wrote:
> On Tue, Mar 26, 2013 at 11:48 PM, Daniel Shahaf <[hidden email]> wrote:
>> We can but that would break an API promise.  (A promise that we might be
>> fine with breaking.)
> I don't see API breakage here:
> 1. We already prohibited some FS paths (with . or ..)
> 2. Only new paths will be affected: users still can access already
> created files/folders in repository.

Agreed I don't see any API promise we're breaking.  What we reject is
an implementation detail.
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Michael Pilato
In reply to this post by Daniel Shahaf-2
On 03/26/2013 04:16 PM, Daniel Shahaf wrote:

> Ivan Zhakov wrote on Wed, Mar 27, 2013 at 00:13:12 +0400:
>> On Tue, Mar 26, 2013 at 11:48 PM, Daniel Shahaf <[hidden email]> wrote:
>>> Ivan Zhakov wrote on Tue, Mar 26, 2013 at 21:57:42 +0400:
>>>> Can we just extend [FS validation] to prohibit all characters with ascii code < 31 ?
>>>
>>> We can but that would break an API promise.  (A promise that we might be
>>> fine with breaking.)
>> I don't see API breakage here:
>> 1. We already prohibited some FS paths (with . or ..)
>> 2. Only new paths will be affected: users still can access already
>> created files/folders in repository.
>
> svn_fs.h:1202
> (I thought I'd given that pointer upthread)
Yup.  That's precisely the comment I was thinking of, too.

--
C. Michael Pilato <[hidden email]>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Michael Pilato
In reply to this post by Daniel Shahaf-2
On 03/26/2013 04:16 PM, Daniel Shahaf wrote:

> Ivan Zhakov wrote on Wed, Mar 27, 2013 at 00:13:12 +0400:
>> On Tue, Mar 26, 2013 at 11:48 PM, Daniel Shahaf <[hidden email]> wrote:
>>> Ivan Zhakov wrote on Tue, Mar 26, 2013 at 21:57:42 +0400:
>>>> Can we just extend [FS validation] to prohibit all characters with ascii code < 31 ?
>>>
>>> We can but that would break an API promise.  (A promise that we might be
>>> fine with breaking.)
>> I don't see API breakage here:
>> 1. We already prohibited some FS paths (with . or ..)
>> 2. Only new paths will be affected: users still can access already
>> created files/folders in repository.
>
> svn_fs.h:1202
> (I thought I'd given that pointer upthread)
Yup.  That's precisely the comment I was thinking of, too.

--
C. Michael Pilato <[hidden email]>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Filenames with trailing newlines wreak havoc

Stefan Sperling
On Tue, Mar 26, 2013 at 04:29:19PM -0400, C. Michael Pilato wrote:
> On 03/26/2013 04:16 PM, Daniel Shahaf wrote:
> > svn_fs.h:1202
> > (I thought I'd given that pointer upthread)
>
> Yup.  That's precisely the comment I was thinking of, too.

That comment was written by Jim Blandy many years ago (r838152).

It is older than FSFS. So technically, this comment has been
violated ever since FSFS has been made default, because the
design of FSFS clearly didn't take this comment into account.
If it had, we wouldn't be having this discussion.

I think we can safely ignore whatever that comment is saying,
or rather, is failing to say, about control characters.
123