# Update scanning an existing beets database

**URL:** <https://discourse.beets.io/t/update-scanning-an-existing-beets-database/1052>\
**Category:** Help\
**Created:** [January 4, 2020, 9:24am UTC](https://discourse.beets.io/t/update-scanning-an-existing-beets-database/1052 "2020-01-04T09:24:22Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![adrian](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/adrian/32/4_2.png) [@adrian](https://discourse.beets.io/u/adrian)\
**Post date:** [January 4, 2020, 5:15pm UTC](https://discourse.beets.io/t/update-scanning-an-existing-beets-database/1052/2 "2020-01-04T17:15:16Z")

</div>

> [@evand](#):
>
> Looking at the two databases I don’t see any difference in what beets has written with and without the -i directive.

It’s true—beets doesn’t keep track of the incremental-import state in the database. Instead, that goes in a special file on the side, called `state.pickle`, in the beets configuration directory (usually `~/.config/beets`).

> [@evand](#):
>
> how do I then get beets to rescan the library adding only new directories and deleting any that may no longer exist?

Beets actually has two different answers to these two questions:

- For new music, that’s what incremental import mode is for. However, it can get a little confusing when you’re importing _to_ the same directory you’re importing _from_. That’s why the Getting Started guide recommends keeping the “inbox” separate from the “library” to keep this straight. But it should still _probably_ work, most of the time, for in-place imports!
- For deleted music, that’s (half of) what the `update` command does.

> [@evand](#):
>
> how does beets handle pruned and/or grafted subdirectories (representing albums) that have been moved around or deleted within the directory structure?

Beets does not really have an answer for this beyond just letting you remove them and then import them again in their new location. This is because I think a good solution to tracking “moves” would be impossible! The filesystem doesn’t actually keep track of moves & renames—it just looks like one file disappeared and a new one appeared. So beets _could_ try to do something like scan for files that have identical contents, but that would require (a) merely guessing about what moves happened in the past, and (b) computing, storing, and keeping up to date hashes of the contents, which would be extremely costly in the “common case” even when it’s never used.

---

_[View the full topic](https://discourse.beets.io/t/update-scanning-an-existing-beets-database/1052)._