Mac: Support projecting symbolic links

[wilbaker]

Resolves #285

The changes in this PR include support for the following (on Mac):

• Creating symbolic links (where appropriate) when expanding folders
• Projection changes scenarios where links change to files (and vice versa)
• Modification of tracked symbolic links

The changes in this PR do not include support for:

• Detecting the creation of new symbolic links within the repo
• Upgrading to a version of Git that reports untracked symbolic links (whose paths are included in ModifiedPaths.dat)

(Support for these scenarios will be added in a follow up PR for issue #320)

[sanoursa]

Just a quick code review pass for now. I'll try to look more deeply later, but don't block on me.

[wilbaker]

@kewillford thanks for the feedback 👍

[sanoursa]

To me, part of the value of creating a new type is to not pay the cost of masking every time we access a property. I would either store it as a ushort and add helper methods for masking (still keeping those details private to the parsing code), or else make this a class with separate fields. I also don't see much value in making this a struct.

[wilbaker]

I also don't see much value in making this a struct.

The value I saw in using a struct if we avoid having to store reference + data in memory.

What do you see as the downside of using a struct?

[wilbaker]

@sanoursa @kewillford I just pushed a commit that simplifies the usage and implementation of FileTypeAndMode. I still need to add the additional functional tests suggested by Kevin, but please let me know what you think of the latest FileTypeAndMode changes.

[nickgra]

FileTypeAndMode makes sense to me. LGTM assuming the rest of the tests come in the next iteration.

[kewillford]

Looks good. Just a few clean up questions.

[sanoursa]

Would an InvalidDataException suffice here?

[wilbaker]

I went with a custom exception here so that:

• This code would be consistent with the approach used in OnGetFileStream
• We can differentiate this error from other InvalidDataException exceptions that might occur inside the lambda (see catch statements below).

Unfortunately this is one spot in the code we need to use exceptions to return errors to the caller.

[sanoursa]

We don't actually support gitlinks right? If we ever see a repo with this data, we may want to fail hard as early as possible, rather than wait and see...

[wilbaker]

I thought about making a change so that we'd throw when parsing the index if we encounter a git link (i.e. submodule).

However, doing so would allow someone to make their repo unmountable:

1. Clone repo
2. Add git submodule
3. The next time VFS for Git parses the index it would throw an exception that results in GVFS.Mount.exe shutting down
4. Repo cannot be mounted or repaired

This also seemed outside the scope of adding symlink support, and so if we do want to add this validation (and prevent a repo from becoming unmountable) it's probably a big enough task to put in its own PR.