End of line sequence changing sometimes

[BillDenton]

• VSCode Version: Code 1.8.1 (ee428b0, 2016-12-19T14:49:23.350Z)
• OS Version: Windows_NT ia32 6.1.7601
• Extensions:

Extension	Author	Version
read-only-indicator	alefragnani	0.4.0
alignment	annsk	0.3.0
bettertab	arenl	1.0.1
Doxygen	bbenoist	1.0.0
python	donjayamanne	0.5.5
EditorConfig	EditorConfig	0.3.4
vscode-great-icons	emmanuelbeziat	1.1.38
matlab	Gimly81	0.4.0
status-bar-tasks	GuardRex	0.1.2
vscode-dimmer	hoovercj	2.1.0
docthis	joelday	0.3.9
cpptools	ms-vscode	0.9.3
vscode-clearcase	OpenNingia	1.4.1
vscode-icons	robertohuertasm	6.0.0
theme-cyanicpastels	SamuelLampa	0.0.9
indenticator	SirTori	0.2.1
vscode-hexdump	slevesque	1.1.4
code-spell-checker	streetsidesoftware	0.14.5
comment-snippets	Tobiah	0.2.0
dark-plus-material	vangware	0.1.4
change-case	wmaurer	1.0.0
highlight-trailing-white-spaces	ybaumes	0.0.2

---

Steps to Reproduce:

1. Edit a file and save.
2. Externally (e.g. WinMerge) compare with previous version.
3. All lines show as different because the line ending has changed.
   This happened to me a few times. Working in Windows with Windows line endings.

[mjbvz]

Can please you try running code with --disable-extensions to see if an extension is the root cause here?

[BillDenton]

I'll try but it is intermittent so I don't know how to trigger it.

[dbaeumer]

@BillDenton without additional information it is very hard to track this down. I will close the issue for now. If you can provide the information please ping and we will reopen the issue.

[BillDenton]

Just had it happen again, but still no idea how. There doesn't seem to be a keybinding for it, so it can't have been accidental typing. I found the problem externally (when diffing using WinMerge). Checking using hexdump (https://marketplace.visualstudio.com/items?itemName=slevesque.vscode-hexdump) shows that the affected file only has 0A at the end of the lines, whereas unaffected files have "0D 0A" at the end of lines.
The affected file still shows "Win32" at the bottom right. I attempted to change line ending by clicking on "Win32" and selecting another ending. Without doing an edit nothing appears to happen. I would have expected the buffer to become dirty. So I guess I don't understand what that does.
Using Ctrl+Shift+P Change End of Line Sequence allowed me to fix it. Unless I managed to accidental type this when doing another command. Is there a command log or debug log anywhere I could check to see if I did this?

[BillDenton]

As I'm working in Windows nearly all of my source code files have windows line endings. However, we have some files that are imported into our project from an external source. The line endings in these files match the external source which is Unix line endings. When I open these files the line ending is immediately converted to Windows. This gives a dirty file, which when I close it prompts me to save it. I haven't any (manual) edits to this file. I'm hitting this problem a lot in the debugger as my program has a breakpoint in this file (to allow catching of an exit).
So the problem appears to be that the line ending has been automatically converted from that on disk. It should detect and maintain the current line ending.
Please re-opened this issue.

[BillDenton]

This looks like a duplicate of Automatically detect encoding of the file opened, which may (hopefully) be in the February iteration plan.

[alexdima]

fyi @bpasero

[bpasero]

I cannot reproduce, I have 2 files on Windows, one using LF and one using CRLF and I can open each of them and the status bar shows the correct line endings and the files are not getting dirty out of the box. Please provide more info to reproduce.

[BillDenton]

Just checked again using release build with extension; still fails.
Checked today's insider build without extensions; it is OK.
So either it is fixed or it is an extension issue. Is there a way of starting without any extensions.

[bpasero]

From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

[BillDenton]

Checked with "code --disable-extensions" with release build and it doesn't occur. So must be an extension. I'll do some selective disabling to identify the extension..

[BillDenton]

In 1.10.1 I started using the original file that highlighted this problem. I'm not seeing the issue, but the file which has 0x0A line endings shows as Win32 in the status bar. Checked the line endings using hexdump . So it appears that the line end detection is broken.