15

During a few years, in my $HOME directory a lot of hidden files and directories appeared.

I would like to continually delete the unneeded ones.

How can I find out which applications created those hidden files and directories.

How can I be sure that it's safe to remove the hidden files and directories and nothing important will be lost and nothing depending on them won't stop working?

  • 2
    Ascertaining what applications created the folders and files can be tricky. Usually correlating the files associated with apps made by decent developers is straightforward, but this is not always the case. If you find a good answer, I for one would like to know what it is. – 0xSheepdog Oct 8 '15 at 16:07
  • 2
    @0xSheepdog auditd for the future - for the history, pretty much nothing. – Jenny D Oct 13 '15 at 11:10
  • Make sure you have a backup of the files before you remove them. (This includes verifying that you can restore the files.) – Jenny D Oct 13 '15 at 11:11
  • 1. Are you using Linux? Which kernel version? (major/minor only please) 2. Is SELinux enabled or can you enable it? 3. Do you have root access? – Otheus Oct 16 '15 at 9:25
14

You can just temporarily displace them.

cd ~
mkdir .trash
find . ! -name . -prune ! -type d -atime +365 -exec \
    sh -c 'touch -a -- "$@"
           mv -- "$@" ~/.trash
    ' --   {} +

That will find all files in your $HOME directory - without recursing into child directories - which have not been accessed for a year. It will update the access time for all of them to right now, and then move all of them into a directory named .trash. If you encounter any problems between the time you run it and whatever time you decide to start deleting old files in ~/.trash then you can try moving some of them back and see if any of those you put in the trash were the cause.

  • While this doesn't technically answer the question, I think it's a pretty good workaround. – Jesse K Oct 13 '15 at 20:26
  • 1
    @JesseKeilson - i think that it does technically answer the question: How can I be sure that it's safe to remove the hidden files and directories and nothing important will be lost and nothing depending on them won't stop working? – mikeserv Oct 13 '15 at 22:15
  • 1
    Some filesystems are mounted with "noatime" option. The atime will never be modified, even if the mtime or ctime are. This will lead your find to wrongly move recent files. – Adrien M. Oct 15 '15 at 10:39
  • @AdrienM. - thats true. by and large, though, every sane fs i come in contact with uses relatime instead. from man mount: relatime: Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but it doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.) and anyway, use -m and -mtime to work w/ modtime. or whatever you like. – mikeserv Oct 16 '15 at 5:32
  • It doesn't answer the 'and directories" part of the question. For that you'd need to walk each .directory, and check all of the files are older than a year. – naught101 Jan 23 '18 at 5:23
6
+100

If you are root of your system, you can use the audit kernel feature to have the maximum information about who/when/what accessed/created/modified files. see this tutorial for debian-flavored examples

If do not have root access, you could use a crontab or a script with an infinite loop+sleep to run lsof & grep files in your homedir. See manpage of lsof. However, it will only display your applications that have a filedescriptor opened at the moment you launch lsof. Should an application open a file, edit it, then close it, you won't see this change in lsof.

a one-liner like this should do the job : lsof -u $(id -u) 2>/dev/null |grep -P $HOME'/[^\s]*$'

Another way is to use the inotify kernel API to check when a file is being accessed. Alas, it's an async system, and you won't have details like "what app", "precisely when", "what user". You'll only have a callback about "this file was modified/accessed...". Some applications (Inotify, FAM, gamin) provides you simple access to the api

  • I just tried to use inotify to trigger lsof. The system is simply too fast for this idea to work: the process is often gone or has closed the file before lsof can be run. In some cases, this might still work, but probably very few. – Otheus Oct 16 '15 at 10:20
  • auditd It's the only system that provides you all details, without missing anything, as it's using specific code path in the kernel. All other tools will miss information, miss data as process will be terminated / have closed the fd. – Adrien M. Oct 16 '15 at 10:36
  • Agreed. I was just putting inotify to the test and confirming that it won't really do the job required here. – Otheus Oct 16 '15 at 15:44
3

You can look for atime and remove files not used for a long time (provided you did not configure your system not to use atime), but that's rather risky (see tmpreaper if you want to go this way).

Instead I'd suggest Bleachbit, an interactive GUI program to remove cruft.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.