0

We're sharing SYMLINKD files on our git project. It almost works, except git modifies our SYMLINKD files to SYMLINK files when pulled on another machine.

To be clear, on the original machine, symlink is created using the command:

mklink /D Annotations ..\..\submodules\Annotations\Assets

On the original machine, the dir cmd displays:

25/04/2018  09:52    <SYMLINKD>     Annotations [..\..\submodules\Annotations\Assets]

After cloning, on the receiving machine, we get

27/04/2018  10:52    <SYMLINK>      Annotations [..\..\submodules\Annotations\Assets]

As you might guess, a file target type pointing at a a directory [....\submodules\Annotations\Assets] does not work correctly.

To fix this problem we either need to:

  1. Prevent git from modifying our symlink types.
  2. Fix our symlinks with batch script triggered on a githook

We're going we 2, since we do not want to require all users to use a modified version of git.

My limited knowledge of batch scripting is impeding me. So far, I have looked into simply modifying the attrib of the file, using the info here: How to get attributes of a file using batch file and https://superuser.com/questions/653951/how-to-remove-read-only-attribute-recursively-on-windows-7.

Can anyone suggest what attrib commands I need to modify the symlink?

Alternatively, I realise I can delete and recreate the symlink, but how do I get the target directory for the existing symlink short of using the dir command and parsing the path from the output?

sbgdev
  • 36
  • 5
  • It's not simply a matter of attributes. The relevant attributes are the directory and reparse-point attributes, but you can't set them. A directory symlink has to be a file-system directory node that contains a symlink reparse point. You'd have to read the link target and recreate the link properly. I don't recommend parsing out the target from CMD's `dir` command, and `fsutil reparsepoint query [filename]` doesn't return the link in a useful format. You need a better scripting or system language, as suggested by kostix. – Eryk Sun Apr 27 '18 at 13:18

1 Answers1

1

I think it's https://github.com/git-for-windows/git/issues/1646.

To be more clear: your question appears to be a manifestation of the XY problem: the Git instance used to clone/fetch the project appears to incorrectly treat symbolic links to directories—creating symbolic links pointing to files instead. So it appears to be a bug in GfW, so instead of digging it up you've invented a workaround and ask how to make it work.

So, I'd better try help GfW maintainer and whoever reported #1646 to fix the problem. If you need a stop-gap solution, I'd say a proper way would be to go another route and script several calls to git ls-tree to figure out what the directory symlinks are (they'd have a special set of permission bits; you may start here).

So you would traverse all the tree objects of the HEAD commit, recursively, figuring out what the symlinks pointing at directories are and then fixup the matching entries in the work tree by deleting them and recreating with mklink /D or whatever creates a correct sort of symlink.

Unfortunately, I'm afraid trying to script this using lame possibilities of cmd.exe-s scripting facilities would be an exercise in futility. I'd take some more "real" programming language (PowerShell as an example, and—since you're probably a Windows shop—even a .NET would be OK).

kostix
  • 51,517
  • 14
  • 93
  • 176