Harden parsing of messages from pipe

[jamill]

This bug presents itself when you stage a region in VS Code.

Open a GVFS Repository with VS Code
Make some changes to a file
Select a region of the file in the editor, right click and “Stage selected range”

This is the command run:

/.git/hooks/pre-command.exe update-index --cacheinfo 100644 '7e012a87091a0f76de43fcbd83098b3611791643
' Scripts/ReinstallGVFS.bat --git-pid=20360

Notice the newline in the command.

The InMount process does not like this, and crashes with something similar to (this doesn't necessarily correspond to the instance above):

The parsedCommand is an unexpected length, got: 123 from message: '7580|False|False|123|git update-index --cacheinfo 100644 f7ce833c943b1d4e33fce3c842236c9c044561c9'\r\n

If this is a valid format for a git command, then VFS for Git should be able to parse it.

[wilbaker]

I believe the root cause of the issue in VFSForGit is that it uses the newline character to separate messages on the pipe (and uses ReadLine to read in new messages).

The hook process is not stripping the newline before passing the command to VFSForGit, resulting in it only reading in a part of the message.

[benpeart]

I don't know of one specifically but there could be a situation where stripping the newline out will cause other/different problems. In general, we've had to use a nul to indicate EOL (and a double nul to indicate the end of the list) when communicating with git and other hooks (see the read object hook for an example).