Chroot boundary crossed error when cloning symlinks pointing outside the repo

[osklyar]

Cloning a repository that contains symlinks pointing outside of the repository structure itself (for sure relative with too many .., but possibly also absolute ones) causes chroot boundary crossed error and leaves the worktree and index in a broken state: random items staged as deleted, other cloned but marked as untracked etc. Using the geat tool and the following two repositories (one contains a valid and a broken symlink, but within the repo, and the other contains a relative symlink outside of the repo, with too many ..) the following is observed:

➜  tmp geat clone [email protected]:osklyar/symlinks-good  
=> in symlinks-good cloned from [email protected]:osklyar/symlinks-good as origin
➜  tmp git:(master) geat status -d symlinks-good
=> in . the state is clean on branch master
➜  tmp git:(master) ls -la symlinks-good/symlink-container 
total 8
drwxr-xr-x 2 skol skol 4096 Jun 20 17:00 .
drwxr-xr-x 4 skol skol 4096 Jun 20 17:00 ..
lrwxrwxrwx 1 skol skol   10 Jun 20 17:00 broken -> ../missing
lrwxrwxrwx 1 skol skol    9 Jun 20 17:00 target -> ../target
➜  tmp geat clone [email protected]:osklyar/symlinks-broken
fatal: failed to clone [email protected]:osklyar/symlinks-broken into symlinks-broken: clone: chroot boundary crossed
➜  tmp git:(master) ✗ geat status -d symlinks-broken
=> in . the state is modified on branch master
   staged:
    D symlink-container/external

Expected behaviour: broken symlinks, including those leading outside the repository, are cloned as they are and left broken.

[smola]

@mcuadros you were recently working on this, any insight on how to solve it properly?

[osklyar]

The problem is within billy.v3 and its implementation of FileSystem for OS. If first tries to ensure the directory and fails there, but if that error is processed for the case of out of Chroot boundary then the stdlib Symlink fails. It is generally not an issue for the stdlib Symlink to create a broken link (pointing to a non existent object), so it can be solved there. The memory implementation would probably need a similar fix.