I have quite a lot of external hard-drives, and often have a hard time finding what I'm looking for - not to mention not storing the same file several times on different drives or finding free space when I need. I was therefor wondering if there are any database-programs suitable for storing the content of disks; including filenames, size and modification dates?

Generally, the more automated the program is in searching each disk and parse information about the files, the better. Ideally, it should use a checksum (or something) to identify an identical files. A database that also stores information about each disk - like partitioning, format (filesystems) and free space remaining (on each partition) - would be a plus.

I have MySQL and PostgreSQL, as well as Apache with PHP, running on my computer, so I can use solution based on these. Though I'm really after a more specialized stand-alone program; at least for managing collections, but preferably specialized for keeping track of files on multiple disks.

I'm also open to unconventional approaches (using a program intended for something else). Has anybody had a similar problem and found a good solution?

  • 1
    I think you are taking the wrong path (the most difficult one). Have you already looked into solutions to manage multiple hard drives like RAID and LVM, and the awesome filesystems ZFS and Btrfs? If not, don't look for anything else! Apr 27 '13 at 23:47
  • I would start from this list: en.wikipedia.org/wiki/…
    – gelraen
    Apr 28 '13 at 12:11
  • Is there any specific operating system involved? Some desktop-systems come with integrated search-engines.
    – Nils
    Apr 29 '13 at 12:43

It sounds like what you want is some sort of media content database. There are multiple such available; a few that you may want to have a look at are:

Since these are primarily meant for cataloging CDs and DVDs, they should have no problem even if the different hard disks are mounted at the same location.


After some scouring I found this to list all files in a directory recursively:

ls -R $PATH | awk '
NF&&f{ print s"/"$0 }'

So then what I would do, would be to save this as a script called listall.sh,

ls -Rlah / | awk '
NF&&f{ print s"/"$0 }'

have a program run it frequently as:

./listall.sh > ~/filelist

and then whenever you want to find a file, you could run:

cat ~/filelist | grep [whatever filename, date, or size you want]

This is the best way I could come up with. What do you think?

  • Fast indexing script (in an unused terminal): while :; do ./listall.sh > ~/.filelist.temp; mv ~/.filelist.temp ~/filelist; done Apr 29 '13 at 22:59
  • Also, you might want to run the entire thing as root (i.e.: sudo -s), because otherwise you will get many error denied messages and it won't index the entire filesystem (from root). Apr 30 '13 at 3:31
  • 1
    You shouldn't parse the output of ls. With this approach, you are not able to handle file names with newlines correctly. Besides, this suggestion is awfully similar to what locate does. Typically you'd have updatedb run daily as a cronjob to update a database of files. This database is subsequently used by locate to find file names in an efficient manner. Oct 30 '13 at 8:04
  • Do you have ANY idea how old this is to resurrect, just because of that? Oct 31 '13 at 2:23

Maybe you can (simply) use a desktop search software, Tracker for instance, which is able to browser, index and give you the possibility to search with an advanced Query Language your database.

It won't work if you mount your different disks on the same mount point.

I guess that you will need to mount them on different mount point: for instance disk "Black" on /mnt/disk/black or /media/black, and so on.

You'll be then be able to triage by yourself with the location path, and if triage by disk if you want by adding a search criteria on the start of location path.

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.