Should Timeshift snapshots be excluded from mlocate's update process? [SOLVED]

[oblong]

As I understand it, mlocate keeps the database /var/lib/mlocate/mlocate.db as an index to allow the system to find files. Is there any point in the Timeshift snapshots being indexed? In other words, should the timeshift directory be included in the PRUNEPATHS line in /etc/updatedb.conf to exclude it from being indexed?

I presume excluding timeshift will speed up the indexing process and reduce the size of mlocate.db. Are there disadvantages to doing this?

[rene]

As I understand it, mlocate keeps the database /var/lib/mlocate/mlocate.db as an index to allow the system to find files.

Fair point about the timeshift snapshots but first of all...

Not "the system" as such but only the command line tool (m)locate. And that is to say that if you, as I, do not in fact use locate you may as well disable the updatedb run and delete the database outright to more fundamentally "speed up the indexing process and reduce the size of mlocate.db":

Code: Select all

sudo chmod -x /etc/cron.daily/mlocate
sudo rm /var/lib/mlocate/mlocate.db

Re-enabling is simply

Code: Select all

sudo updatedb
sudo chmod +x /etc/cron.daily/mlocate

I have personally likely never experienced wanting to know the location of a file I did know the name of other than in those situations handled by which or maybe dpkg -L already, or when doing/creating something now for which locate does't help anyway, it needing to wait for an updatedb run. And that's while I am a command line user: for the majority of Linux and certainly Mint users the locate/updatedb system is a complete waste of resources.

That said: if someone does care for the daily updatedb runs excluding /timeshift does probably make sense in and of itself. You may wish to message forum admin xenopeek; he probably knows how to most effectively suggest this to the Mint crew.

[xenopeek]

I presume excluding timeshift will speed up the indexing process and reduce the size of mlocate.db. Are there disadvantages to doing this?

Don't know what impact it has but there's not disadvantage to doing this. I'd guess nobody expects when using locate to find a file on their system, to report where all it is in Timeshift snapshots.

The user can configure where Timeshift should save snapshots so I'd guess this would actually need to be implemented in the Timeshift setup screen. That when the user selects or changes where to save snapshots, Timeshift also (offers to) change the updatedb configuration to exclude that specific path?

I'm not in favor of disabling mlocate as rene suggests. Various GUI search tools also use the mlocate database for finding files on your system. It's—by a wide margin—the fastest way available on Linux to find files by (partial) name.

[rene]

The user can configure where Timeshift should save snapshots so I'd guess this would actually need to be implemented in the Timeshift setup screen.

/etc/updatedb.conf unfortunately does not seem to support any form of globbing so it's a bit unwieldy, but seems that

Code: Select all

PRUNENAMES="snapshots snapshots-boot snapshots-daily snapshots-hourly snapshots-monthly snapshots-ondemand snapshots-weekly"

would work as a general setting; simply PRUNENAMES="timeshift" would unfortunately exclude f.e. also /usr/share/timeshift.

[gm10]

I wouldn't be opposed to disabling mlocate/updated by default but I don't agree that timeshift should be pruned by default if it remains enabled. If I use locate I expect to find all instances on my filesystem.

An option in timeshift settings to add it to PRUNEPATHS sounds like a good idea though.

[oblong]

Thanks for the replies. I've excluded timeshift and the database is definitely smaller, and the update process runs for less time. No apparent problems. Marked it as solved.