thecbproject / diffpatch Goto Github PK

I am currently using this tool in a project, and since some editors seem to be particularly annoying about messing with trailing newlines even when told not to, a feature like this would be very useful, for clarification if necessary, a trailing newline is a newline at the very end of a file, if this can't be added, a workaround suggestion would be appreciated, i'd implement it myself but this looks very complicated and i'm not sure if i would be able to 😅

Logfile: https://gist.github.com/Bricktricker/67bbcf61eafe403d240060dfe798874d (from orig. reporter on The Forge Project discord)

The given lines are the root of the issue here: when OutputPath#isFile() is true, OutputPath#toPath() is called to convert the path into a Path object.
However, this causes an issue when the outputPath variable holds a PipePath: PipePath returns true for #isFile() but throws an UnsupportedOperationException for #toPath() (presumably because you cannot obtain a Path object for pipes). This causes the aforementioned crash via UnsupportedOperationException.

Although there is an if-check present before those lines, which short-circuits when the outputPath is a Pipe, this only returns and stops when the PipePath does not have a ArchiveFormat. If the PipePath does contain an ArchiveFormat, then this if-check passes and it goes straight into the aforementioned currently-crashing code.

The bug was reported via a user using ForgeGradle 4.0.14 and 4.0.15 (with 4.0.14 being the version of ForgeGradle that first switched to DiffPatch). The offending code which causes the issue is this, where a ByteArrayOutputStream with an archive format of ArchiveFormat.ZIP is given as the output path of the PatchOperation
https://github.com/MinecraftForge/ForgeGradle/blob/a74f4b155d3c41f495e4e03398ead9a95ef831f8/src/userdev/java/net/minecraftforge/gradle/userdev/MinecraftUserRepo.java#L1033-L1044

Hey, so not sure if this is a bug or intentional.

If you delete a folder, it will generate patches for all the text files in the folder to be deleted, but will leave behind any binary files like images, jar files etc.

Not sure if #8 fixes this or not

Test Case
Relevant Stack Trace

Description:

One potential solution:
Default to name if the patchedPath is either null or /dev/null
Fixing that causes a secondary issue where the target files are still created with empty contents