Hacker News Reader

Comment by dendory | Hacker News Reader

He was unlucky and didn't think things through too much, especially when dealing with such imporant files, but I agree with him that the way it's implemented is silly. If you provide a program that syncs your documents, with the name of your files, to your local system, people expect these files to be your actual documents, not empty links. Every other online storage system works that way. If you move a file out of your skydrive or Dropbox sync folder you have the actual file, not an empty link.

View on HN

Dropbox also doesn't have the (IMHO) unnecesary "trash can" metaphor. You can easily recover deleted files through the web interface. If you want to delete something and make it unrecoverable, it's possible but you really have to go out of your way.

But how could that possibly work for a document that's edited in a browser? What file format would such a document be stored in when there's no local editor available for it?

Good question. Seems a pretty simple solution: the browser is the editor, even if the files are local. We use browsers to interact with local files all the time, for example during local web app development.

Only that's impossible as it is now (and will be for the forseeable future) because it wouldn't be very wise to give browser apps write access to the local filesystem.

You would not need to be able to edit the offline file. Instead it could still be just a link to the online version of the file, like it is now. But additionally it could contain the actual data that can be imported back to Google servers when it is accidentially deleted from the server.

I was replying to the part where "even if the files are local" i.e. not on the net.

Isn't it the Google Drive application that updates those files?

sandboxes.

http://developer.chrome.com/apps/fileSystem.html

The google drive already has access to the local filesystem, so that is a not a good reason to not have a local copy of the data.

Who knows? I don't know the internals of my Word or Pages documents. Why should anyone care what the internals of a .gdoc file look like? It could be anything. But nobody expects it to be a mere "pointer" link.

> I don't know the internals of my Word or Pages documents. [...] But nobody expects it to be a mere "pointer" link.

While Word and Excel (and plenty of other kinds of non-cloud document) files usually contain data besides links, and sometimes contain no links, they can contain content which is non-obviously (from visual inspection) provided through a link which is broken if the file is moved. And, unlike gdocs, you don't usually get a warning when you drag them out of the folder which tells you exactly what is going to happen if you do that.

When you drag something out of your folder on your local machine, how does gdocs give you a warning? (I'm curious, having never tried it.)

I'm assuming there is a background process that monitors the folder for changes. On my machine there is about a 3.5 second delay between moving the file and getting the warning. And if you click "OK, move to trash" it only trashes it in gdrive, you still have the file wherever you moved it. It's not a finder dialog box and can get lost behind other windows. It's bizarre UI.

> I'm assuming there is a background process that monitors the folder for changes.

I would assume its the same Google Drive background process that syncs changes made to files in the folder back to Drive, just using special handling for the case of "you moved a file that is a link to content in a Google web service and rather than a normal file".

How about a proprietary binary format that would reload the data if it was synced back to Drive/Docs at a future time? As the format evolves, an online tool could at least extract csv/text versions of older data from the original files.

Edit: HDF5 is great for storing OT data too, even if the operations and handling are proprietary.

Reply on news.ycombinator.com