On Tue, Mar 08, 2022 at 09:18:27AM +0100, Omar Polo wrote:
> woops, i've been a bit sloppy in the way I'm generating the temporary
> file while applying the patch.  (but i couldn't replicate locally)
> 
> I need to open a new temporary file during the patch operation to
> accumulate the changes/additions to the target file before rename(2) it
> to the destination file.
> 
> It's fine to just use "./"?  it's the only instance in the codebase, but
> I can't use /tmp because I need both files (temp and destination) to be
> on the same filesystem for rename(2) to work.  got_opentemp guarantees
> us that it's a new file, so no chance to corrupt existing files in the
> worktree.

Using relative paths internally is a receipe for bugs.
We should always use absolute paths internally, and convert to relative
paths only at the presentation layer where the user gets to see them.

> I could have used GOT_WORKTREE_GOT_DIR (concatenated to the worktree
> root path) but that would require to build a string and "./" saves us an
> allocation :)

Using absolute paths you will have to build a path in a new buffer.

The tests are failing because the generated temp path is outside the
unveiled path space. That is why open reports "no such file or directory".

For example, given this test prefix:

  /ramdisk/got-test/got-test-patch_dont_apply-j0GwTNKr

The work tree used by the test was here:

  /ramdisk/got-test/got-test-patch_dont_apply-j0GwTNKr/wt/

And this file is outside the work tree, and hence cannot be opened:

  /ramdisk/got-test/got-test-patch_dont_apply-j0GwTNKr/wt-veJJZC