If reversing a patch succeeds does that always mean the patch had been fully applied?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












9














This is touched on in two questions, 'Check if a file or folder has been patched already' and 'Make patch return 0 when skipping an already applied patch' however neither had a satisfying answer.



I am writing a script and want to test the following for a patch:



Fully applied: continue



Partially applied: exit



Not applied: if it can be applied successfully do it and continue, otherwise exit



The problem is handling the partially applied case:



mkdir test && cd test

cat << EOF > foobar.patch
--- /dev/null
+++ foo
@@ -0,0 +1 @@
+foo
--- /dev/null
+++ bar
@@ -0,0 +1 @@
+bar
EOF

patch --forward -i foobar.patch
rm foo


So bar exists but foo doesn't because at some point it was removed. Now if I apply the patch forward in a dry-run the exit code is 1 since it's not applied successfully.



$ patch --dry-run --forward --force -i foobar.patch
checking file foo
The next patch would create the file bar,
which already exists! Skipping patch.
1 out of 1 hunk ignored
$ echo $?
1


That does not tell me whether the patch is fully applied though, just that it failed the dry-run. I don't know why that's marked correct as the stackoverflow answer. I tried reversing but since it's a non-interactive script it only worked with force:



$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file foo,
which does not exist! Applying it anyway.
checking file foo
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file bar
$ echo $?
1


So does it always hold that if I try to forcibly reverse a patch in a dry-run and it succeeds that the patch is fully applied, and if it fails that it's not fully applied (or applied at all)? Because if so then I can do something like



patch --dry-run --reverse --force -i foobar.patch ||
(patch --dry-run --forward --force -i foobar.patch &&
patch --forward --force -i foobar.patch) ||
exit 1









share|improve this question























  • Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
    – roaima
    Sep 19 '16 at 7:23






  • 1




    @roamia well the patch and script are under my control. only my script would be applying the patch.
    – Jay
    Sep 19 '16 at 16:46










  • I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
    – Jasen
    Dec 25 '16 at 12:01
















9














This is touched on in two questions, 'Check if a file or folder has been patched already' and 'Make patch return 0 when skipping an already applied patch' however neither had a satisfying answer.



I am writing a script and want to test the following for a patch:



Fully applied: continue



Partially applied: exit



Not applied: if it can be applied successfully do it and continue, otherwise exit



The problem is handling the partially applied case:



mkdir test && cd test

cat << EOF > foobar.patch
--- /dev/null
+++ foo
@@ -0,0 +1 @@
+foo
--- /dev/null
+++ bar
@@ -0,0 +1 @@
+bar
EOF

patch --forward -i foobar.patch
rm foo


So bar exists but foo doesn't because at some point it was removed. Now if I apply the patch forward in a dry-run the exit code is 1 since it's not applied successfully.



$ patch --dry-run --forward --force -i foobar.patch
checking file foo
The next patch would create the file bar,
which already exists! Skipping patch.
1 out of 1 hunk ignored
$ echo $?
1


That does not tell me whether the patch is fully applied though, just that it failed the dry-run. I don't know why that's marked correct as the stackoverflow answer. I tried reversing but since it's a non-interactive script it only worked with force:



$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file foo,
which does not exist! Applying it anyway.
checking file foo
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file bar
$ echo $?
1


So does it always hold that if I try to forcibly reverse a patch in a dry-run and it succeeds that the patch is fully applied, and if it fails that it's not fully applied (or applied at all)? Because if so then I can do something like



patch --dry-run --reverse --force -i foobar.patch ||
(patch --dry-run --forward --force -i foobar.patch &&
patch --forward --force -i foobar.patch) ||
exit 1









share|improve this question























  • Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
    – roaima
    Sep 19 '16 at 7:23






  • 1




    @roamia well the patch and script are under my control. only my script would be applying the patch.
    – Jay
    Sep 19 '16 at 16:46










  • I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
    – Jasen
    Dec 25 '16 at 12:01














9












9








9


5





This is touched on in two questions, 'Check if a file or folder has been patched already' and 'Make patch return 0 when skipping an already applied patch' however neither had a satisfying answer.



I am writing a script and want to test the following for a patch:



Fully applied: continue



Partially applied: exit



Not applied: if it can be applied successfully do it and continue, otherwise exit



The problem is handling the partially applied case:



mkdir test && cd test

cat << EOF > foobar.patch
--- /dev/null
+++ foo
@@ -0,0 +1 @@
+foo
--- /dev/null
+++ bar
@@ -0,0 +1 @@
+bar
EOF

patch --forward -i foobar.patch
rm foo


So bar exists but foo doesn't because at some point it was removed. Now if I apply the patch forward in a dry-run the exit code is 1 since it's not applied successfully.



$ patch --dry-run --forward --force -i foobar.patch
checking file foo
The next patch would create the file bar,
which already exists! Skipping patch.
1 out of 1 hunk ignored
$ echo $?
1


That does not tell me whether the patch is fully applied though, just that it failed the dry-run. I don't know why that's marked correct as the stackoverflow answer. I tried reversing but since it's a non-interactive script it only worked with force:



$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file foo,
which does not exist! Applying it anyway.
checking file foo
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file bar
$ echo $?
1


So does it always hold that if I try to forcibly reverse a patch in a dry-run and it succeeds that the patch is fully applied, and if it fails that it's not fully applied (or applied at all)? Because if so then I can do something like



patch --dry-run --reverse --force -i foobar.patch ||
(patch --dry-run --forward --force -i foobar.patch &&
patch --forward --force -i foobar.patch) ||
exit 1









share|improve this question















This is touched on in two questions, 'Check if a file or folder has been patched already' and 'Make patch return 0 when skipping an already applied patch' however neither had a satisfying answer.



I am writing a script and want to test the following for a patch:



Fully applied: continue



Partially applied: exit



Not applied: if it can be applied successfully do it and continue, otherwise exit



The problem is handling the partially applied case:



mkdir test && cd test

cat << EOF > foobar.patch
--- /dev/null
+++ foo
@@ -0,0 +1 @@
+foo
--- /dev/null
+++ bar
@@ -0,0 +1 @@
+bar
EOF

patch --forward -i foobar.patch
rm foo


So bar exists but foo doesn't because at some point it was removed. Now if I apply the patch forward in a dry-run the exit code is 1 since it's not applied successfully.



$ patch --dry-run --forward --force -i foobar.patch
checking file foo
The next patch would create the file bar,
which already exists! Skipping patch.
1 out of 1 hunk ignored
$ echo $?
1


That does not tell me whether the patch is fully applied though, just that it failed the dry-run. I don't know why that's marked correct as the stackoverflow answer. I tried reversing but since it's a non-interactive script it only worked with force:



$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file foo,
which does not exist! Applying it anyway.
checking file foo
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file bar
$ echo $?
1


So does it always hold that if I try to forcibly reverse a patch in a dry-run and it succeeds that the patch is fully applied, and if it fails that it's not fully applied (or applied at all)? Because if so then I can do something like



patch --dry-run --reverse --force -i foobar.patch ||
(patch --dry-run --forward --force -i foobar.patch &&
patch --forward --force -i foobar.patch) ||
exit 1






patch






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 21 '18 at 22:36









studog

26516




26516










asked Sep 19 '16 at 7:09









Jay

464




464











  • Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
    – roaima
    Sep 19 '16 at 7:23






  • 1




    @roamia well the patch and script are under my control. only my script would be applying the patch.
    – Jay
    Sep 19 '16 at 16:46










  • I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
    – Jasen
    Dec 25 '16 at 12:01

















  • Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
    – roaima
    Sep 19 '16 at 7:23






  • 1




    @roamia well the patch and script are under my control. only my script would be applying the patch.
    – Jay
    Sep 19 '16 at 16:46










  • I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
    – Jasen
    Dec 25 '16 at 12:01
















Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
– roaima
Sep 19 '16 at 7:23




Is the source code under your control, ie can you guarantee that all patches will always apply exactly once?
– roaima
Sep 19 '16 at 7:23




1




1




@roamia well the patch and script are under my control. only my script would be applying the patch.
– Jay
Sep 19 '16 at 16:46




@roamia well the patch and script are under my control. only my script would be applying the patch.
– Jay
Sep 19 '16 at 16:46












I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
– Jasen
Dec 25 '16 at 12:01





I think it's possible to contrive a starting point and a patch that would succeed fully in both forward and reverse directions.
– Jasen
Dec 25 '16 at 12:01











1 Answer
1






active

oldest

votes


















1














With this diff:



diff --git a/bar b/bar
new file mode 100644
index 0000000..e69de29
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo


this happens:



$ cd /tmp/test
$ patch --forward -i foobar.patch
patching file bar
patching file foo
$ echo $?
0
$ rm bar
$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file bar,
which does not exist! Applying it anyway.
checking file bar
checking file foo
$ echo $?
0


So the answer to your question is no.






share|improve this answer




















  • Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
    – Jay
    Jan 22 '17 at 23:47










  • It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
    – Jay
    Jan 23 '17 at 7:38










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f310765%2fif-reversing-a-patch-succeeds-does-that-always-mean-the-patch-had-been-fully-app%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














With this diff:



diff --git a/bar b/bar
new file mode 100644
index 0000000..e69de29
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo


this happens:



$ cd /tmp/test
$ patch --forward -i foobar.patch
patching file bar
patching file foo
$ echo $?
0
$ rm bar
$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file bar,
which does not exist! Applying it anyway.
checking file bar
checking file foo
$ echo $?
0


So the answer to your question is no.






share|improve this answer




















  • Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
    – Jay
    Jan 22 '17 at 23:47










  • It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
    – Jay
    Jan 23 '17 at 7:38















1














With this diff:



diff --git a/bar b/bar
new file mode 100644
index 0000000..e69de29
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo


this happens:



$ cd /tmp/test
$ patch --forward -i foobar.patch
patching file bar
patching file foo
$ echo $?
0
$ rm bar
$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file bar,
which does not exist! Applying it anyway.
checking file bar
checking file foo
$ echo $?
0


So the answer to your question is no.






share|improve this answer




















  • Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
    – Jay
    Jan 22 '17 at 23:47










  • It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
    – Jay
    Jan 23 '17 at 7:38













1












1








1






With this diff:



diff --git a/bar b/bar
new file mode 100644
index 0000000..e69de29
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo


this happens:



$ cd /tmp/test
$ patch --forward -i foobar.patch
patching file bar
patching file foo
$ echo $?
0
$ rm bar
$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file bar,
which does not exist! Applying it anyway.
checking file bar
checking file foo
$ echo $?
0


So the answer to your question is no.






share|improve this answer












With this diff:



diff --git a/bar b/bar
new file mode 100644
index 0000000..e69de29
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo


this happens:



$ cd /tmp/test
$ patch --forward -i foobar.patch
patching file bar
patching file foo
$ echo $?
0
$ rm bar
$ patch --dry-run --reverse --force -i foobar.patch
The next patch, when reversed, would delete the file bar,
which does not exist! Applying it anyway.
checking file bar
checking file foo
$ echo $?
0


So the answer to your question is no.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 22 '17 at 9:16









aferber

36115




36115











  • Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
    – Jay
    Jan 22 '17 at 23:47










  • It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
    – Jay
    Jan 23 '17 at 7:38
















  • Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
    – Jay
    Jan 22 '17 at 23:47










  • It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
    – Jay
    Jan 23 '17 at 7:38















Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
– Jay
Jan 22 '17 at 23:47




Thank you for pointing that out. I've found I can fix for that case by using --posix since it will set an error when there's no file to patch. However using POSIX mode will not set an error if a file to be deleted contains content that differs from the patch. For example if I run that reverse command with --posix and the bar file contains some data then in POSIX mode the file will not be deleted and no error occurs. Therefore my fix is run it both with and without posix mode and if both are ok then I assume the patch was successfully applied. I will update my question to reflect this.
– Jay
Jan 22 '17 at 23:47












It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
– Jay
Jan 23 '17 at 7:38




It appears --posix may not be the cure-all I thought it was. If a file is deleted by a patch and I run --posix --reverse then it errors that the file does not exist. I'll have to look into this more tomorrow.
– Jay
Jan 23 '17 at 7:38

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f310765%2fif-reversing-a-patch-succeeds-does-that-always-mean-the-patch-had-been-fully-app%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay