# Populating file list from restore takes ages

Finally uploaded my 3 terabytes of data.
But clicking the “list files” button takes ages to load.
WIndows even claims the program stopped responding and can be closed.
Here is a screenshot:
https://puu.sh/y266A/d316a1de41.png

If you run the CLI version from the dos prompt it will be much faster:

cd path\to\repository


This is mainly because the GUI version restores to a different directory and the local cache has to be rebuilt.

ah okay. i counted, and a single time populating the file lists takes 25 minutes. quite crazy but at least works quite fast afterwards!
are there plans to implement this in the GUI?
So the GUI version restores from google drive and the cli uses the cache?
The way the GUI works you can have literary a fresh computer right with no files installed on it?

The GUI version is a wrapper around the CLI version so it is the CLI version that does everything. The difference is the GUI version always restores to a different directory so there isn’t a local cache to take advantage of. The CLI version can also be used to restore on a fresh computer by initializing a new repository with the same repository id and the storage url.

Wait, so with the GUI i cannot restore from a other computer?

It can. Copy from another thread:

For the GUI version, you can create an empty directory on another computer as the repository and then select the same storage. Under the restore tab you can click list revisions and select the repository id of the original repository and then you will be able to list all files in the original repository and select them to restore.

You can also restore using the CLI version by running the following commands:

mkdir -p path/to/restore/to
cd path/to/restore/to
duplicacy init repository_id storage_url
duplicacy restore -r n   # n is the revision number that you want to restore


For the init command you need the repository id of the original repository. You can find it out by listing the snapshots directory in the storage.