Double backslashes disappear from code

Question

Not the first time it happens on the site, so it's time to raise the problem in Meta.

It is similar, but distinct from ‘double backslash + newline’ collapses to ‘single backslash’ when I hit ‘edit’ (Nov 26 '10); what happens is that code with lines ending with \\ gets randomly transformed, without any intervention, into a single backslash and the following line becomes a continuation of the line previously ending with \\.

The code for sure had double backslashes when it was posted.

See the edit history at https://tex.stackexchange.com/posts/146730/revisions (Nov 24 '13) for the last time I was made aware by it in some code of mine, look at the comment How to typeset row operations on augmented matrix

• Another case I remember is How to correctly format (and align) a LaTeX proof? (Sep 2 '11) where my answer was fixed by Andrew Swann and, when I went to see what edit had been done, I discovered the same problem in azetina's answer.

• Here is another example: How to align a set of multiline equations (Feb 13 '12) (a second degraded answer, by Werner, fixed; Feb 13 '12; except that the intended fix isn't present, but fixed now)

Other examples:

• Vertically align cell table in figure (Dec 2 '12)

• Set math fonts to predefined color (Sep 4 '13)

• Using \gather and \align together (Apr 3 '12) (all answers, but not the question, are affected)

• Label rows of a matrix by characters (Jun 13 '12)

• Hyperref TextFields dont't work when in tabular environment with xetex? (Sep 26 '13) (the question)

• How to write conditional equations with one-sided curly brackets (Mar 7 '12)

• Commutative Diagrams (May 23 '13)

• How to create alternating rows in a table? (Nov 14 '10) (an answer)

• Modify eqnarray to match that of amsmath's align (Jan 31 '13)

• Table overlay in beamer on multiple rows (Nov 21 '12)

• Rotated column titles in tabular (Oct 25 '11)

• Diagram of an artificial neural network (Sep 9 '13)

• Aligning plain align and cases? (Nov 1 '11)

• TikZ matrix as a replacement for tabular (May 18 '11) (both question and answer)

• vertical-lines-in-a-multirow-and-multicolumn-table (Jan 2 '13)

Update

In view of the provisional answer given below, please only add examples that appear to be affected after February 22, 2015, below this comment.

Latest date (so far) of corrected example: December 20, 2013: https://tex.stackexchange.com/a/150816/579. (Please update this date if a later example is found. The aim is to pinpoint the likely period in which the offending change was applied in order to determine the cause.)

Examples

(empty, for now, hope it remains so)

Update: April 27, 2017

Nick Craver seems to have found the origin of the problem. While he blames himself, I think we shouldn't put him at the wall and fire. ;-)

The proposal he made seems quite appealing, particularly if the items edited while in the specific review queue aren't bumped to the top page. With all candidates collected in a queue, we should be able to get away with the issue soon.

An additional request would be to have two buttons: “Fix” and "Pull off the queue”, the latter for posts that are just false positive.

A good search criterion for a post being included in the list seems to be

it contains a backslash followed by four spaces or a TAB, and has been posted before 2013-12-31

Answer 1

Update: This was almost certainly my fault.

On December 20, 2013 I moved the TeX (and meta) databases to new homes. I'm not sure how the original problem occurred, but TeX and its meta had a very odd database collation. Of the hundreds of databases, it was only those. We didn't recognize this for several years until we started aggregating data across databases for several network screens (think: top bar, achievements, rep, etc.).

The only way to fix this online and permanently (not ending up with a two-off database with a different structure) was to make a new Tex database and migrate things over. This happened by making TeX/meta read-only, moving the data in the background, and swapping the connection over at the end. But it appears that the strange collation the database was on handled double backslashes particularly in an odd way that did not convert to SQL_Latin1_General_CP1_CI_AS cleanly.

I looked back at our internal chat logs, and a hint that this was an issue didn't reach our ears until July 15th, 2015. Unfortunately, we don't keep data forever and by years later, those database backups were long gone.

We can't just fix this because we don't have the data, but we're looking at options to help scale out fixing this quickly, for example possibly a new review queue we can populate with these posts for quick fixing by many. We don't have the data to do this with 100% accuracy, and we can't trust a query would be 100% accurate either, but populating a queue to very quickly.

Before we go down that road, is that an appealing option? There are other uses for such functionality, e.g. when we detect images that are no longer there and posts need some love, etc.

Answer 2

Based on \\ corruption, I've created a new query

TeX.SX \\ corruption (based on user ID)

which I hope will help anyone to find their own posts affected by this bug!

P.S. The database is updated every sunday, so the query will return also updated Q&A until the database is refreshed...

Answer 3

This and the linked question

‘double backslash + newline’ collapses to ‘single backslash’ when I hit ‘edit’

Are two manifestations of the same issue, see

Community effort in fixing the double backslashes issue

For a summary of how this got fixed in the end.

Answer 4

I've looked into it and I couldn't find anything specific. The thing is, we don't ever modify markdown w/o recording history. So when you read about rebakes and other stuff we do, those are affecting the conversion from markdown to html, with markdown always staying the same.

To me, this looks like a one off job that somebody ran on the DB that touched post history (where markdown is stored). This would still leave the HTML of the post the same. The same holds true for markdown updates. Everything happens in the rebake.

Recently, however, we did multiple rebakes. One was adding rel="noreferrer" to links in order to mitigate the window.opener vulnerability, and another one was for fixing imgur links to https (which again was only a rebake). Those rebakes then surfaced the markdown change, long after it happened.

So the question that still has no answer is, who touched the post history (and when). Unfortunately I couldn't find the answer to that. But it's definitely not caused by anything that's running in production currently.