If Storage::syncSaves() is called when sync is running, another sync
would be automatically scheduled in the end of the current one.
That could be helpful when we want to specify that we changed something
during sync (created new save slot, for example).
It now supports only one storage of each type. Only one Storage could be
loaded to the memory as well.
Options' Cloud tab now changes the Storage only when user pressed OK
button, giving the ability to look through the Storages without actually
changing them.
GoogleDriveDownloadRequest, which resolves file id and then downloads it
with GoogleDriveStorage::downloadById().
GoogleDriveStreamFileRequest, which resolves file id and then returns
file stream with GoogleDriveStorage::streamFileById().
This commit also adds GoogleDriveStorage::streamFileById() itself.
A minor GoogleDriveResolveIdRequest fix added.
With these one can download files from Google Drive.
Because of the Google Drive StorageFile now contains yet another field,
`id`. For other storages `id` == `path`, and thus all common Requests
(such as SavesSyncRequest, DownloadFolderRequest, etc) must be using
id() instead of path(). That way these Requests won't cause id resolving
which could be quite slow (when you call it for all files in the folder,
for example).
Now openForLoading() and openForSaving() check whether file is locked,
so AGOS and SCUMM engines Ctrl+number and Alt+number hot keys shouldn't
be able to save/load in these slots during saves sync.
Engines with "simple" savenames would support "Run in background" in
save/load dialog and gradual save slots unlocking. Other engines
save/load feature would be locked until save sync is over.
Now it also creates the "base" ScummVM directory if there is no such
directory yet. This way SavesSyncRequest works fine when no "ScummVM" or
"ScummVM/Saves" folder exist in the Google Drive.
It now keeps newly added Requests in separate array, so iterators don't
break when one adds a Request while ConnMan iterates its array.
The array is also shielded with mutex.
When listing directories, you get a list of StorageFiles, which path()
is actually Google Drive id. Thus, if you list a directory recursively,
you won't be able to determine whether all files are within one
directory or have some hierarchy. I'd fix that as soon as it would be
needed.
GoogleDriveResolveIdRequest gets a lowercase path and searches for the
specified file's id. To do that it lists path's subdirectories one by
one with GoogleDriveListDirectoryByIdRequest.
GoogleDriveListDirectoryByIdRequest gets a Google Drive id and lists
that directory (not recursively).
Alexander Tkachev
Peter Bozsó