Trying update app fix #64
Conversation
| @@ -89,6 +89,10 @@ auto InstallUpdate(ProgressBox* pbox, const std::string url, const std::string v | |||
| file_path = fs::AppendPath("/", file_path); | |||
| } | |||
|
|
|||
| if (!strcasecmp(strrchr(file_path.s, '/'), "/sphaira.nro")) { | |||
There was a problem hiding this comment.
won't this always be true? i am not 100% sure what it's supposed to fix. is it for custom sphaira locations? if so, the solution would be check to check we are not hbmenu, check the output path against the exe path and if different, copy the file to exe path using progress box copy file function. let me know if this is what you want, and i'll accept the merge (once this strcasecmp is removed) and do the above change :)
There was a problem hiding this comment.
Maybe I haven't understand this part of the code correctly, for me the var file_path is the actual file path contained into the zip downloaded so I test if the file is the sphaira.nro file (extracting the last string starded with a "/" with strrchr() and comparing if it is "/sphaira.nro") and if it is it force the path to be ExePath to write the nro to the place where the nro executed is for this file specificly. With that if the zip downloaded contain others files (maybe in futur it will not contain only the nro) the files will be copied like the zip structure except the nro witch will be copied over the ExePath.
With previous code the nro was copied where the zip structure tells to copy it, or I have realy not understand the code witch is also a possibility.
There was a problem hiding this comment.
yes it extracts the file from zip into the correct path. overriding it to exe path isn't ideal as if exepath is hbmenu, then it will only update hbmenu and not /switch/sphaira/sphaira.nro - which is common for users to have forwarders installed to.
There was a problem hiding this comment.
I see but if you launch the nro from "/switch/sphaira.nro" or an other path than "/switch/sphaira/sphaira.nro" it will never be updated? And if the user launch it from the forwarder it will update the nro launched by the forwarder and if it's "/switch/sphaira/sphaira.nro" and if the HBMenu replacement param is enabled the "/hbmenu.nro" will also be updated when exiting.
Personaly I think the update should only update the nro launched, it the best way to not create a double of the homebrew witch ould be not wanted. For example if I have "/switch/sphaira.nro" and if Sphaira also replace the HBMenu and if I launch the update from the HBMenu it will create a third Sphaira in "/switch/sphaira/sphaira.nro", same thing if I launch "/switch/sphaira.nro" except that it will never be updated witch in that case is a real problem.
Or an other solution, we could keep my modification and I can add a copy of the Exe Path after writing the file in "/switch/sphaira/sphaira.nro" but we could have the same problem of a double not wanted.
My last idea could be to keep my modification, then search all Sphaira occurences in the homebrew list and update all of them but for this I'm not sure that I will know how to do it correctly. And with this solution the problem is that maybe the user want to have different versions of the homebrew (for testing for example) and in that case this will not be possible anymore except if the homebrew is in a non-standard path.
In fact we haven't a perfect solution.
|
Thanks for the pr! good job finding that bug. i didn't consider the version in the exe path getting overridden in an update |
|
I see that you've fixed one point of this pr when fixing issue #66 (I've integrated it in this PR to fix conflicts) so should we close this pr or we could continue to discuss about my update process in main_menu.cpp or not? |
Signed-off-by: shadow2560 <[email protected]>
Tried to fix updating the app in some circonstances (if the nro of Sphaira is in a non standard path or even if it is in "/switch/sphaira.nro") and modifying some logs messages. It's a realy simple approach but it should works in most cases.
I've also modified how Sphaira could replace "/hbmenu.nro" if it's launched as HBMenu cause update process of the app could now replace "/hbmenu.nro" and if version downloaded by the update is more recent than the one present in "/switch/sphaira.nro" or "/switch/sphaira/sphaira.nro" they can replace the updated version, I've supposed that it is not what we want.