更新时间:2023-12-02 17:28:58
今天下午,我一直在努力解决这个确切的问题,试图恢复朋友的Dropbox的状态,被相同的勒索软件击中。我不知道您是否仍然需要解决方案,但是总的来说,这是一种状态。
I've been scratching my head over this exact problem this afternoon, to try and restore the state of a friend's Dropbox which got hit by the same ransomware. I don't know whether you're still in need of a solution, but in a nutshell, here's the state of play.
在Dropbox API V2中,每个文件都有唯一的ID。这在删除,重命名,移动等操作中保持不变。这是解决此问题的关键,因为Dropbox会按文件路径跟踪文件历史记录,因此,勒索软件重命名文件后,可以选择以编程方式简单地回滚文件丢失。要使事情变得更加困难,请获取目录列表,其中 include_deleted
设置为True,您会注意到Dropbox在元数据删除中不包含文件ID。如果他们这样做了,那将是一件轻而易举的事。
In Dropbox API V2, every file has a unique ID. This is persisted across deletes, renames, moves, etc. This will be key to fixing this problem, as Dropbox tracks file history by file path, so as soon as the ransomware renamed your files, the option of simply rolling back your files programmatically was lost. To make things even more difficult, fetch a directory listing with include_deleted
set to True and you'll notice that Dropbox don't include file IDs in the metadata for deletions. If they did, this would be a breeze.
因此,这是替代方法:
将该文件列表分为两个列表:现有文件和已删除文件:
Split that list of files into two lists, existing files and those that have been deleted:
已删除=列表(过滤器(lambda文件:isinstance(file,dropbox.files.DeletedMetadata),files.entries))
deleted = list(filter(lambda file: isinstance(file, dropbox.files.DeletedMetadata), files.entries))
(其中 files
是 dropbox.files.ListFolderResult
的实例>)
dropbox.Dropbox.files_list_revisions
来获取修订列表。进行第一个修订,它将是最新的,并将其ID存储在文件路径旁边。这就是我们获取已删除文件的ID的方式。dropbox.Dropbox.files_list_revisions
. Take the first revision, which will be the newest, and store its ID alongside the file path. This is how we get an ID for a deleted file.我故意将实际的实现方式交给您,但希望对您有所帮助。
I've purposefully left the actual implementation in code up to you, but I hope this helps.