Ckan: [Bug] Superfluous metadata changed message with non-normalized install_to

Created on 26 Sep 2019 · 20Comments · Source: KSP-CKAN/CKAN

already third time I got

possibly an every bot iteration

Bug Core (ckan.dll) Metadata Registry

Source

yalov

All 20 comments

and again I got the message

yalov on 27 Sep 2019

Tried this just now, doesn't happen for me. Please share your registry.json file so we can look into why it's happening for you.

Did you install this from your own .ckan file while testing or something like that?

HebaruSan on 27 Sep 2019

have you waited after installing? The message is showed up on the next launch of CKAN after some hours.
there is registry:
https://www.dropbox.com/s/judm3gmugs5jr19/registry.json?dl=0

yalov on 27 Sep 2019

Since this issue has no reproduction steps (hint, hint :wink:), I took my best guess and installed it and then refreshed.

Thanks, having a look a the registry.json now...

HebaruSan on 27 Sep 2019

The file looks fine, the metadata for the module is the same between the available and installed versions...

Tried replacing my registry with yours and refreshing, still no popup.

HebaruSan on 27 Sep 2019

It should be noted that the bot had about an 18 hour nap during the time period of this reported issue. So the only change to the metadata has been the download counts.

techman83 on 28 Sep 2019

Yeah, this file has not been updated after it was first added:

https://github.com/KSP-CKAN/CKAN-meta/commits/master/CommunityPartsTitlesExtrasNoCCKDup/CommunityPartsTitlesExtrasNoCCKDup-0.5.0.ckan

HebaruSan on 28 Sep 2019

And I got it again. Maybe filters of CPT and CPTEC doesn't work (or set) right and somehow change the local metadata?

Do you succeed in reproduction?
Enable repos autoupdate on a startup, install all 3 mods: the CPT and 2 CPTExtras, exit CKAN, and after 24h open CKAN again.

yalov on 28 Sep 2019

I can confirm this issue. No idea where this comes from though. Really weird.

DasSkelett on 4 Oct 2019

Found the difference:

$ diff CPTNENCCKD-available.txt CPTNENCCKD-installed.txt
43c43
<             "install_to": "GameData/002_CommunityPartsTitles/Extras/"
---
>             "install_to": "GameData/002_CommunityPartsTitles/Extras"

It loses the trailing slash ~~when transformed to installed module...~~ somewhere in the (re)install process...

DasSkelett on 4 Oct 2019

It downloads the metadata with the slash, but once you click "Yes" for reinstalling and CKAN goes on, the slash is lost in the available module and thus missing in the installed module too.

If you click "No", the slash is kept in the available module...
So maybe the metadata is changed somewhere in the reinstall process?

DasSkelett on 4 Oct 2019

once you click "Yes" for reinstalling

What are the steps to reproduce the initial prompt for reinstalling? It sounds like you have an explanation for why the prompt would repeat, but I was not able to get it to appear once.

HebaruSan on 4 Oct 2019

What are the steps to reproduce the initial prompt for reinstalling? It sounds like you have an explanation for why the prompt would _repeat_, but I was not able to get it to appear once.

Yes indeed, wanted to add reproduction steps to the post, got carried away...

1) Install CommunityPartsTitles, CommunityPartsTitlesExtrasCategory, CommunityPartsTitlesExtrasNoCCKDup and ModuleManager.
2) Wait for the remote repository to have changed, so a refresh updates the registry. Alternatively, close CKAN, change the lasT_server_etag property in the registry to something different, restart ckan.
3) Hit refresh if auto-refresh on start is disabled.
4) The message about the changed metadata appears.

DasSkelett on 4 Oct 2019

Oh wow, that crashed my mono completely:

$ mono _build/ckan.exe
[xcb] Too much data requested from _XRead
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
mono: ../../src/xcb_io.c:742: _XRead: Assertion `!xcb_xlib_too_much_data_requested' failed.

      at <unknown> <0xffffffff>
      at System.Windows.Forms.X11Keyboard:XCreateFontSet <0x000d6>
      at System.Windows.Forms.X11Keyboard:CreateOverTheSpotXic <0x000e7>
      at System.Windows.Forms.X11Keyboard:CreateXic <0x00117>
      at System.Windows.Forms.X11Keyboard:CreateXicForWindow <0x00053>
      at System.Windows.Forms.X11Keyboard:FocusIn <0x000c7>
      at System.Windows.Forms.XplatUIX11:SetFocus <0x000f3>
      at System.Windows.Forms.XplatUI:SetFocus <0x0003c>
      at System.Windows.Forms.ContainerControl:SendControlFocus <0x000c7>
      at System.Windows.Forms.Form:SetVisibleCore <0x0052f>
      at System.Windows.Forms.Control:set_Visible <0x0004b>
      at System.Windows.Forms.Control:set_Visible <0x00083>
      at System.Windows.Forms.Application:RunLoop <0x003df>
      at System.Windows.Forms.Form:ShowDialog <0x00927>
      at System.Windows.Forms.Form:ShowDialog <0x0002b>
      at CKAN.YesNoDialog:ShowYesNoDialog <0x001d7>
      at CKAN.YesNoDialog:ShowYesNoDialog <0x000a3>
      at CKAN.Main:YesNoDialog <0x00057>
      at CKAN.Main:YesNoDialog <0x000af>
      at CKAN.GUIUser:RaiseYesNoDialog <0x0003b>
      at CKAN.Repo:HandleModuleChanges <0x001af>
      at CKAN.Repo:UpdateAllRepositories <0x00577>
      at CKAN.Main:UpdateRepo <0x005cb>
      at System.ComponentModel.BackgroundWorker:OnDoWork <0x00046>
      at System.ComponentModel.BackgroundWorker:WorkerThreadStart <0x000c3>
      at System.ComponentModel.BackgroundWorker:<RunWorkerAsync>b__27_0 <0x00033>
      at System.Threading.Tasks.Task:InnerInvoke <0x00092>
      at System.Threading.Tasks.Task:Execute <0x00037>
      at System.Threading.Tasks.Task:ExecutionContextCallback <0x0005f>
      at System.Threading.ExecutionContext:RunInternal <0x001a7>
      at System.Threading.ExecutionContext:Run <0x00042>
      at System.Threading.Tasks.Task:ExecuteWithThreadLocal <0x000f6>
      at System.Threading.Tasks.Task:ExecuteEntry <0x000e8>
      at System.Threading.Tasks.Task:System.Threading.IThreadPoolWorkItem.ExecuteWorkItem <0x00026>
      at System.Threading.ThreadPoolWorkQueue:Dispatch <0x0028a>
      at System.Threading._ThreadPoolWaitCallback:PerformWaitCallback <0x0001c>
      at <Module>:runtime_invoke_bool <0x00086>

HebaruSan on 4 Oct 2019

👀1

That could be a problem on my system, though. I tried downgrading mono to the version distributed by Ubuntu to test something, then upgraded back to the version from mono-project.com, so something could be out of whack from all of those changes.

EDIT: Maybe a permissions problem with my ckan.exe? It wasn't executable, and after chmodding it the crash has gone away.

HebaruSan on 4 Oct 2019

👍1

I think install_to is changing here, in the TrimEnd call:

https://github.com/KSP-CKAN/CKAN/blob/d79c04a47bde87d98bd1a29b638610630cdf4dc4/Core/ModuleInstaller.cs#L411-L413

https://github.com/KSP-CKAN/CKAN/blob/d79c04a47bde87d98bd1a29b638610630cdf4dc4/Core/KSPPathUtils.cs#L170-L178

That is called during installation, so the string with the trailing slash lasts from refreshing until you install it, at which point the trailing slash is removed from the available module, which is cloned to produce the installed module. So after installation they appear consistent, but then if you refresh again the trailing slash comes back. Kind of a nasty violation of the apparent immutability of a public property.

Looks like a pretty old bug that would affect any module with an install_to that isn't normalized (e.g., with trailing slash). For a short-term workaround, we can normalize the path in the netkan.

For a long-term fix we can follow through on the TODO comment above and normalize paths earlier. Might also make sense to normalize paths anytime we compare them, just in case things like this slip through in the future.

HebaruSan on 4 Oct 2019

Affected netkans:

HebaruSan on 4 Oct 2019

I found that too, but I'm wondering how this changes the stanza of the module in the end, since C# is call-by-value, or am I just brain-dead right now?

DasSkelett on 4 Oct 2019

Isn't it call-by-reference for object types? So the stanza object is passed in, and then its install_to property is assigned, affecting the original object.

HebaruSan on 4 Oct 2019

Yeah, finally found a good explanation of it (but it's German).
For primitives it always copies the value (call-by-value), for "reference types" (objects) it is some mix: the reference to the object is copied. So if you assign a new object to the parameter, it won't affect the outside object, but if you don't and manipulate the parameter, it will be visible outside...

Too wild mix of C and Python the last days...

DasSkelett on 4 Oct 2019

👍1

Was this page helpful?

0 / 5 - 0 ratings