Crash when generating patch for multiple files and a file only on one side

[Simran-B]

WinMerge v2.16.4.0 32 bit / WinMerge v2.16.5.0 64-bit (pre-release) under Windows 10 64-bit

File structure to reproduce the crash:

|__ foo
|   |__ a.txt
|
|__ bar
    |__ a.txt
    |__ b.txt

Demo files: winmerge_patch_crash.zip

1. Drag both folders onto WinMerge and select them

   

2. Click Tools > Generate Patch and set a result path

3. The other options don't matter, but make sure not to change the default [2 files selected]

   

4. Click OK and wait. Crash occurs.

The reason seems to be that it tries to compare in pairs, but doesn't check whether the file exists in both directories.

[sdottaka]

Fixed by commit 8ef3d8e

Thank you for the report.

The latest CI build artifacts are available at:
https://ci.appveyor.com/project/sdottaka/winmerge/build/artifacts

[Simran-B]

Thanks, it does no longer crash with the patch.

The generated patch in unified style is not quite as I expected though:

--- a.txt	Fri Jan 10 14:23:29 2020
+++ a.txt	Fri Jan 10 14:23:29 2020
--- b.txt	Thu Jan  1 01:00:00 1970
+++ b.txt	Fri Jan 10 14:23:29 2020
@@ -0,0 +1 @@
+test
\ No newline at end of file

Git itself gives me this for a commit which transitions a folder from "state" foo\ to bar\

diff --git b.txt b.txt
new file mode 100644
index 0000000..30d74d2
--- /dev/null
+++ b.txt
@@ -0,0 +1 @@
+test
\ No newline at end of file

The first three lines are git-specific, but what I find confusing about the WinMerge patch is that it seems to include +++ filename / --- filename for all files, even if they stay the same, and that an added or removed file shows with its actual filename instead of /dev/null and with a Unix timestamp of 0 converted a string and taking into account my local UTC offset. Is that on purpose or would you mind adjusting it to match what git would produce more closely?

[sdottaka]

Sorry for the slow response.

The current WinMerge diff output mimics the 'diff -N' option.
WinMerge is not git, so I won't try to match it perfectly.
But it was better to output /dev/null as you say, so I fixed it that way.