Where is the project state?

[RenaKunisaki]

I checked my project's .gpr and .rep files into Git a while ago. Now I want to restore them from a previous commit, but it seems like I'm missing something:

1. Open the project
2. Hit G in the Code Browser and type a name
3. Notice a comment in that function which was added after checking into Git
4. Exit Ghidra and check out the files
5. Open the project again
6. The name I entered in step 2 is still the default in the Goto prompt, and the comment from step 3 is still there.

Is something going haywire or are there additional files I need to restore?

[dev747368]

Some state from plugins can be saved in ~/.ghidra/.ghdira_YOURVERSION/tools/_code_browser.tcd

The goto action is such a plugin.

[RenaKunisaki]

That explains the goto, but there's something else going on. It seems like restoring the .gpr and .rep files isn't having any effect. I've restored much older versions from backup, but they still show recent changes.

I notice when I open them there's a "restoring bundle state" dialog; is that perhaps what I need to look at?

[dragonmacher]

Bundle state currently relates to scripting. This would be looking at your <user home>/ghidra_scripts dir. Saved tool values and user preferences are in the dir mentioned by @dev747368. Some of the project settings are saved in your project .rep dir. To help diagnose which settings are at play here, we'd need more info about what is not properly updating.

[RenaKunisaki]

I've tried removing the .ghidra directory and restoring the .rep directory from backup, trying to fix this issue. But no matter how far back I go, I observe the same results:

• Still getting the same error when browsing the data types
• Some functions don't decompile, saying "low-level error: bad structure definition"
• Many function signatures have been lost (functions have local variables in_r3, in_r4... but no arguments)

Is there perhaps a date recorded in the project file somwehre that I can use to verify if the backups are being restored correctly?

[ghidra1]

Be very careful not to overlay an old state on top of the current project state - this could easily occur using Git. Relative to Git, you may very well be mixing versioned and non-versioned files when you attempt to use GIT in this fashion. You should take advantage of Ghidra's versioning instead of using git. Project file versioning within Ghidra is available for private projects without the need for a Ghidra Server. If you insist on using Git you will need to get a clean clone - not just a checkout.

[RenaKunisaki]

Yes, unfortunately I discovered Ghidra's versioning function a bit too late, but seeing how this is dealing with a corrupt database, it might not have helped. At this point I'm restoring from Duplicity backups rather than Git, so it should be restoring the entire project, unless I've done something wrong.

[RenaKunisaki]

Well I still haven't figured out what's going on, but I guess you did answer the question.

[ghidra1]

Each time a project file is saved a new versioned database file (e.g., db.2.gbf) is created within the directory associated with a project file (e.g., foo.rep/idata/00/~00000002.db). Normally the older ones are removed leaving only the most recent. If using Git you checkout an earlier commit without first committing all of the current state, you will bring in older db.#.gbf files without removing the latest dbf files which are un-versioned within Git. When multiple gbf files exist, only the most recent is used and the older ones removed. This may explain why you kept seeing your most recent changes. Keep in mind I am guessing here but it is the most plausible explanation.

[RenaKunisaki]

That does seem to have been the case. Removing all files under SFA.rep and then checking out does get me back to a non-corrupted version. Thank you!

[karsten-burger]

I have the ghidra project dir synchronised with a cloud storage, for backup. But I have the problem that a large number of temporary files populates the cloud storage, tmp*.ps and db.1.gbf, db.2.gbf ..., each about 200 MB large, and smaller ones like changeA.prf and snapshotA.grf .
Is there a way to avoid this?

[ghidra1]

The tmp*.ps (presave) files are created when a file is open for update and should be removed when the file is closed. An automatic presave alternates betweeen to backups as changes are made. This is done to ensure a valid one exists shuould an unexpected failure occur which prevents a proper save and cleanup. Generally, these files should not be widespread unless numerous unexpected failures occur. On the client-side these generally occur when developing with eclipse and process is terminated while project files are open, and on the server-side if connection is lost during a checkin (e.g., client screen-saver). Depending on the operating system, you may see two versions of the *.gbf file (e.g., Windows) where the later one is the important one and the other is the previous version. This two file issue is a known issue with Windows due to an open file handle when we try to remove the old buffer file.

[ostar4335]

"C:\Users\ostar\Desktop\ghidra_11.0.1_PUBLIC\support.." -jdk_home -save' is not recognized as an internal or external command

all jdk's and java are installed...

[ostar4335]

update: whole .bat file system doesn't work + windows can't update

[ryanmkurtz]

I think you entered this info in the wrong discussion.