DropBox Mac 客户端如何工作？
我一直在研究 DropBox Mac 客户端，目前正在研究实现类似的不同服务的接口。
他们究竟是如何与这样的取景器交互的？ 我非常怀疑文件夹中表示的这些对象是每次加载时下载的实际文档吗？ 它们必须根据需要动态下载。 那么如何在没有实际文件系统对象的情况下在 Finder 中显示这些项目呢？
有人知道这是如何在 Mac OS X 中实现的吗？
或者有任何指向 Apple API 或与 finder 具有类似集成的其他开源项目的指针吗？
I've been looking at the DropBox Mac client and I'm currently researching implementing a similar interface for a different service.
How exactly do they interface with finder like this? I highly doubt these objects represented in the folder are actual documents downloaded on every load? They must dynamically download as they are needed. So how can you display these items in finder without having actual file system objects?
Does anyone know how this is achieved in Mac OS X?
Or any pointer's to Apple API's or other open source projects that have a similar integration with finder?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Dropbox 可能会使用 FSEvents 来监视文件系统。 这是一个很棒的 API，甚至可以捆绑应用程序未运行时发生的更改。 它与 Spotlight 使用的 API 相同。 菜单栏应用程序可能会自行进行实际观察（例如，因为重新启动它可以修复挂起的上传）。
他们不可能使用 MacFUSE，因为这需要安装 MacFUSE 内核扩展才能使 Dropbox 工作，而且由于我绝对没有安装它，我非常怀疑他们正在使用它。
Dropbox is likely using FSEvents to watch for changes to the file system. It's a great API and can even bundle up changes that happened while your app was not running. It's the same API that Spotlight uses. The menubar app likely does the actual observing itself (since restarting it can fix uploads being hung, for instance).
There's no way they're using MacFUSE, as that would require installing the MacFUSE kernel extension to make Dropbox work, and since I definitely didn't install it, I highly doubt they're using it.
两个建议：
前者将允许您编写一个显示为文件系统并执行所有正确操作的应用程序； 后者将允许您将所有内容移动到服务器端，并让用户将您的服务安装为文件共享。
Two suggestions:
The former will allow you to write an app that appears as a filesystem and does all the right things; the latter will allow you move everything server-side and let the user just mount your service as a file share.
Dropbox 不由 MacFUSE 或 WebDAV 提供支持，尽管这些可能是您想要完成的任务的完美解决方案。
如果它是由这些东西提供支持的，那么当你没有连接时它就无法工作，因为它们都依赖服务器来存储实际信息，而 Dropbox 则不然。 如果我退出 Dropbox（通过菜单项完成）并断开网络连接，我仍然可以使用这些文件。 那是因为这些文件实际上存储在我的硬盘上。
这也意味着这些文件不需要“每次加载时都下载”，因为它们实际上存储在我的机器上。 相反，仅通过线路发送增量，并且 Dropbox 应用程序（在后台运行）适当地修补文件。 另一方面，Dropbox 应用程序监视 Dropbox 文件夹中的文件，当它们发生更改时，它会将适当的增量发送到服务器，服务器将它们传播到任何其他客户端。
这种设置有一些明显的优势：它可以在离线时工作，速度快一个数量级，并且对其他应用程序是透明的，因为它们只看到磁盘上的文件。 但是，我不知道它如何处理合并冲突（这很容易在一个或多个客户端离线时出现），如果服务器是唯一的副本并且每次编辑都会更改该中央副本，那么这不是问题。
Dropbox 真正出色的地方在于，他们有一个额外的技巧，可以将 Dropbox 文件夹中的项目标记为当前同步状态。 但这不是你在这里问的。
就目前的问题而言，您绝对应该研究 MacFUSE 和 WebDAV，它们可能是您问题的完美解决方案。 但 Dropbox 的处理方式（通过后台应用程序更改磁盘上的实际文件）可能是更好的权衡。
Dropbox is not powered by either MacFUSE or WebDAV, although those might be perfectly fine solutions for what you're trying to accomplish.
If it were powered by those things, it wouldn't work when you weren't connected, as both of those rely on the server to store the actual information and Dropbox does not. If I quit Dropbox (done via the menu item) and disconnect from the net, I can still use the files. That's because the files are actually stored here on my hard drive.
It also means that the files don't need to be "downloaded on every load," since they are actually stored on my machine here. Instead, only the deltas are sent over the wire, and the Dropbox application (running in the background) patches the files appropriately. Going the other way, the Dropbox application watches for the files in the Dropbox folder, and when they change, it sends the appropriate deltas to the server, which propagates them to any other clients.
This setup has some decided advantages: it works when offline, it is an order of magnitude faster, and it is transparent to other apps, since they just see files on the disk. However, I have no idea how it deals with merge conflicts (which could easily arise with one or more clients offline), which are not an issue if the server is the only copy and every edit changes that central copy.
Where Dropbox really shines is that they have an additional trick that badges the items in the Dropbox folder with their current sync status. But that's not what you're asking about here.
As far as the question at hand, you should definitely look into MacFUSE and WebDAV, which might be perfect solutions to your problem. But the Dropbox way of doing things, with a background application changing actual files on the disk, might be a better tradeoff.
对我来说，这感觉就像是一个经过大量修改的版本控制系统。 它具有所有功能：基于增量更新文件、恢复或还原文件旧版本的选项。 感觉就像他们正在使用 git (GitFS?) 或某些文件系统他们设计的。
To me it feels like a heavily modified revision control system. It has all the features: updates files based on deltas, options to recover or restore old revisions of files. It almost feels like they are using git (GitFS?), or some filesystem they designed.
客户端上的Dropbox是用python编写的。
客户端似乎使用 sqlite3 数据库来索引文件。
我想 Dropbox 将文件分割成块，以减少带宽使用。
顺便说一下，两个人有同一个文件，即使互不认识，服务器也可以优化，避免多次传输文件，只在服务器端复制
Dropbox on the client is written in python.
The client seems to use a sqlite3 database to index files.
I suppose Dropobox split a file in chunks, to reduce bandwith usage.
By the way, it two people has the same file, even if they do not know each other, the server can optimize and avoid to transfer the file more times, only copying it on the server side
您还可以尝试一下文件传送器。 它是一个 Python 守护进程，能够立即检测 FS 更改（在 Linux 上通过
inotify，在 OS X 上通过FSEvents）、处理文件并同步它们。前往一个或多个目的地。支持的协议：FTP、SFTP、Amazon S3（还支持 CloudFront）、Rackspace 云文件。 可以轻松扩展。 使用
django-storages。“处理文件”：例如优化图像、转码视频 - 最初设想用于在加速网站的情况下将静态资产发送到 CDN）
You could also give File Conveyor a try. It's a Python daemon capable of instantly detecting FS changes (on Linux through
inotify, on OS X throughFSEvents), processing the files and syncing them to one or more destinations.Supported protocols: FTP, SFTP, Amazon S3 (CloudFront is also supported), Rackspace Cloud Files. Can easily be extended. Uses
django-storages."processing files": e.g. optimizing images, transcoding videos — this was originally conceived to be used for sending static assets to a CDN in the context of speeding up websites)