2

A program I installed splattered files and directories in different places. I'm having to manually remove these files and directories. I know you can delete files and directories created by a user like this:

# find /home -user student -exec rm -rf {} \;

Is there a way to do the same for a program by specifying the name of the program that you want to have its files and directories removed?

7
  • What program, and how did you install it — and what OS? Commented Jul 11, 2018 at 11:05
  • Why the downvote? Commented Jul 11, 2018 at 11:09
  • @Jeff Schaller The program is called anaconda but it shows up mostly as anaconda3 and sometimes as anaconda. OS is fedora linux. Commented Jul 11, 2018 at 11:10
  • Did you use dnf or rpm or yum or...? Commented Jul 11, 2018 at 11:13
  • @ Jeff Schaller , I had to check first with dnf. It was a long time ago but guess I downloaded it from here, because dnf only shows 1 anaconda installed which must be the fedora system installer which is called anaconda too. Commented Jul 11, 2018 at 11:21

5 Answers 5

3

As Hans-Martin Mosner said in his answer, there is no information stored that identifies what program created or modified a particular file or directory.

However, you may use find to find things that a program possibly created or modified. You may do this by first creating a "timestamp file" and then run the program. After the run, find may be asked to locate all modified files based on their timestamps in relation to the timestamp file.

  1. Create timestamp file:

    touch stamp 
  2. Run program.

  3. Run find to locate things whose modification time is newer than the timestamp file:

    find / -newer stamp 

    or, if you know what user supposedly owns the files,

    find / -user someuser -newer stamp 

Note that the find command may take a considerable time to run unless you can narrow down the / top-level search path to a specific subdirectory where the modifications may have taken place. Also note that any pathname that the above find command produces may not have been touched by the specific program that you ran. Any number of other programs may have been running since the stamp file was created and may also have created or changed files.

1

If you know before you run the program, then you can mark the program set-gid to a special group.

Maybe you can do this and run it again, to see the sort of place that it puts them.

1

If you can make the program write the files again tracefile may be able to help you:

tracefile -ue bash -c 'seq 10 | xargs -n1 touch' 

https://gitlab.com/ole.tange/tangetools/-/tree/master/tracefile

0

No, the filesystem does not store which program created a file. You need to select them manually. If the first run of the program was very recently, you can use find to pre-select files that could possibly have been created by it.

3
  • May be this is a case that warrants the inclusion of such a feature. After all automating such repetitive tasks is part of the reason programming took off in the first place. Commented Jul 11, 2018 at 11:14
  • @MyWrathAcademia Think about that for a while. What would be stored and where? I can have any number of myprogram binaries that can create files. Should each file be associated with the full path to the binary that created it? What would happen if that path was invalidated, either by removing the binary or moving the file to a new system? What if a binary replaces another with the same pathname, would you still trust the "created by" path? Commented Jul 13, 2018 at 9:38
  • Note how Android, for example, uses different user ids per application, mainly to keep them from touching each other's private parts, but such a mechanism could be used in a linux distro when you're prepared to lose some compatibility with other distros. Commented Jul 13, 2018 at 13:49
0

If you know in advance that you want to keep an eye on what a program does a kernel interface such as sysdig or SystemTap could record an audit trail (or possibly strace, but that would be slow and would require a perfect wrapper around the program to be traced and hopefully no sudo is ever run...). You would also need to consider what happens when some other program creates output under the program in question: must what any child process does also be tracked?

perl -e 'qx(echo subshell-io > foo)' 

An audit trail of every file touched by every program (plus other metadata, such as the user and group(s), parent pid, etc) would certainly be possible. This could however be expensive to setup, expensive to generate, and expensive to maintain. It would likely need some means of filtering records to exclude (some, but maybe not all) /tmp directory writes, to possibly roll up multiple write passwd.tmp/rename("passwd.tmp","passwd") calls into one logical operation, also how do you handle the case where the program you are interested in modifies say /etc/passwd (among many other possible shared OS files) that you probably then do not want to blindly remove when cleaning up after the program...or how do you deal with delegated I/O where your program uses dbus and then some other process due to some random not-I/O message over dbus does generate I/O elsewhere because of your program...

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.