Find all files connected with a program on disk...

[MathWizard]

I'm playing an old Star Trek game, ST:Armada 2 with Fleet-Ops ,some re-worked magic so that it runs well in win10. But I can't find the dam save game location, I want to delete my old saves, and doing it in the games UI, is extra tedious and slow.

I know in the past I would delete the saves no problem, but now I don't know the new location.

Searching the net for the save location hasn't helped yet, I don't see it in appdata, or my doc's, games, and I can't find the file extension name to search for.

But since I know exactly where the game is, and all the core files, is there some simple search, or program that can list all files that get run/created/associated, with any other file I want ? Surely windows does this all the time

What should I try ?

[JohnnyMalaria]

I recommend using WinDirStat. It's not really a file search tool as such but it gives you a great way to see where everything is.

You could also run dir from the command prompt and pipe the results into a text file. Clunky but effective. You can limit what it returns but you have to look up the syntax.

There are also tools that will monitor all file operations so you could use one of those while running the game to log what files are being accessed etc. I recommend this: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

[nightfire]

The hard way would be to use procmon (also from sysinternals) and watch while the program execution all function calls- and filter then for disk access to the savegame files...

[T3sl4co1l]

You've checked the likely suspects (My Documents subfolder, Program Data, AppData/Roaming or Local)?

Not many other places it could/should be.  Maybe Registry.

Can't find info on the wiki or anything?  Most games have that kind of info around...

Tim

[JohnnyMalaria]

Any clues on this page? https://www.pcgamingwiki.com/wiki/Star_Trek:_Armada_II (particularly the footnote 1).

When running this game without elevated privileges (Run as administrator option), write operations against a location below %PROGRAMFILES%, %PROGRAMDATA%, or %WINDIR% might be redirected to %LOCALAPPDATA%\VirtualStore on Windows Vista and later (more details).

[nightfire]

Found this, maybe it helps?
https://www.fleetops.net/forums/general/where-are-saved-games-kept-9301

[ebastler]

Do you know (part of) the filename or the extension? Then I recommend "Everything", an extremely fast, lightweight file search tool. It will only find files by name, or part of the name, but it does that pretty much instantaneously, with the help of a file index it collects silently and efficiently.

https://www.voidtools.com/

I don't recall who recommended it to me (might even have been on this forum?), but I am forever grateful to that unknown benefactor. 

[Bud]

Save a game and search the drives for the latest files timestamps.

[Whales]

The hard way would be to use procmon (also from sysinternals) and watch while the program execution all function calls- and filter then for disk access to the savegame files...

Process explorer helped me the other day on a Win10 box trying to find where a program was temporarily stashing a PDF before calling Adobe reader on it.

Zsoft uninstaller can take disk index + registry index snapshots and compare them between two runs.  It's officially for working out what installers do, but it also works to see where config files & save files are kept.

I get into this situation far too often with Windows games on my Linux box.   Luckily I can do something like "strace -f wine game.exe 2>&1 | grep drive_c" and get a list of all files the program opens or writes to, but that's not an option for most users :|

[Nominal Animal]

Just for completeness, if any Linux users end up having the same question, and find this thread:

In Debian-derivative Linux distributions (Debian, Ubuntu, Mint, etc.) one can run
    dpkg-query -S $(which binary)
or
    dpkg-query -S path-to-file
to find the name of the package providing a command or a specific path; and
    dpkg-query -L package
or
    dpkg-query -L $(dpkg-query -S $(which binary) | cut -d ':' -f 1)
or
    dpkg-query -L $(dpkg-query -S path-to-file | cut -d ':' -f 1)
to get the complete file listing.

[Whales]

Note: dpkg is only used in Debian derived distros (Debian, Ubuntu, Mint, etc).  All good package managers will have similar features however.  My pet peeve is when a package of 'name' installs a binary of 'Name', ie capitalised

[Nominal Animal]

All good package managers will have similar features however.

Absolutely true – I would have included the commands for rpm, but don't have a distro installed using rpm packages, and was too lazy to go look them up online.

I do wonder why Microsoft and Apple haven't switched to package management?

It does not need to impact existing installation methods – you can still install software by hand on all Linux distros just fine, even via sudo make install if you are brave –, so backwards compatibility definitely isn't the reason.

Then again, "package management" itself – as a software engineering problem/pattern – is still in flux.  You have installers that put stuff at registered locations, and then you have zero-install ones like AppImage, Flatpak, and Snap that use filesystem images.  Perhaps they just haven't found one that works best for all their users?

[helius]

The actual way one finds files used by a program is lsof and/or dtrace or bpftrace.

[Whales]

I do wonder why Microsoft and Apple haven't switched to package management?

They have for Windows Updates. 

Technically also an uninstaller registration is also a form of package management, but in the Win world they are only centrally listed (not centrally performed).   *nix package managers are very strict in comparison, but I'd argue both options are still in the same universe.

[Nominal Animal]

The actual way one finds files used by a program is lsof and/or dtrace or bpftrace.

There is a difference between "connected" (or "associated with") and "used".  I was talking about the former.

That said, on Linux, I use strace -f -e open,openat,lstat,lstat64,stat,stat64 -o logfile program [args...] to find out which files a program uses: opens or examines the metadata for.  The logfile will list all files (including dynamic libraries) accessed, and the access flags (read-only, read-write, et cetera).  Whales already showed how they use it with Wine, running Windows binaries in Linux (although I prefer my stanza ).

I do wonder why Microsoft and Apple haven't switched to package management?

They have for Windows Updates.

Right!  I didn't think of that; thanks.