Live data from Hacker News

Google Drive: Shortcuts replacing files and folders stored in multiple locations

support.google.com

51–60 of 74 posts

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#51
post #3

I worked on the original (long since superseded) implementation of the metadata store for Google Drive, i.e. the system which was responsible for tracking file / folder relationships. The requirement to allow an item to appear in multiple locations was a huge complication, in part because of the way it interacted with permissions being inherited from a folder to the items in that folder. I imagine this change may be…

Googler, opinions are my own.

This was my understanding as well. The original Drive was built effectively as a directed graph (with cycles allowed). Any file or folder could be stored in multiple locations. And permissions were at a per-file basis, so 2 people viewing the same folder may see different sets of files.

And permissions were definitely a hard part of it, as if you applied new permissions to a folder and all children, it had to walk the entire graph to update the permissions.

This is the advantage of the Team Drive style structure that the Drive team put out. It follows the classic filesystem design of a tree, which allows for easier permissions modeling, among other things. It's also why all "hard links" are now becoming shortcuts / Soft-links.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#52

Shouldn't de-duping be an implementation detail of the virtual file system, completely hidden from the user? Isn't that how file sharing/syncing services have worked since the MegaUpload days? If I upload the same file to two separate folders it's because I want two separate copies. If I change one of the copies, I don't want it to change the other copy.

> If I upload the same file to two separate folders it's because I want two separate copies. If I change one of the copies, I don't want it to change the other copy.

If that's what you were doing, you won't get affected by this. This is about files/folders that were "hardlinked", which was difficult to do by accident. I think you had to hold Ctrl while dragging the file into another folder, or something like that. (The key to notice is that they're talking about one file being in multiple directories, not multiple files with identical contents.)

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#53
post #50
post #47

Slightly related, has anyone moved off Google Drive and into NextCloud or similar and been happy with it? I'm losing access to the unlimited Google Drive storage that my uni provided and trying to figure out where I should move to. A NAS would be great but at this moment I'm too nomadic to want to worry about that. I'm fine with paying but would rather pay an organization that's very respecting of privacy and less li…

I switched from Dropbox to Nextcloud, and within a couple of months from Nextcloud to Google Drive. Really didn't like the software and it was so slow since I wasn't self-hosting it, but renting it from Hetzner. Currently thinking of switching from Google Drive to Syncthing, since the new Google Drive clients suck and Google is going to be making my service worse with the new G Suite changes.

The new Google Drive client is horrible with lots of files. It is doing something very wrong in its sqlite database and completely killing performance of the drive where AppData lives, even if the Google drive folder is on a different disk.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#54

Shouldn't de-duping be an implementation detail of the virtual file system, completely hidden from the user? Isn't that how file sharing/syncing services have worked since the MegaUpload days? If I upload the same file to two separate folders it's because I want two separate copies. If I change one of the copies, I don't want it to change the other copy.

>If I upload the same file to two separate folders it's because I want two separate copies. If I change one of the copies, I don't want it to change the other copy.

That's precisely the behavior you'll get. You were allowed in the previous implementation to upload a file to one location and then put it in 2 locations, such that you would have changes in either location reflected the same way. This wasn't 'copying' a file, it was multiparenting it.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#55
post #11

"The process will replace all but one location of files and folders that are currently in multiple locations. The files and folders will be replaced with shortcuts." Is there any way for the user to specify that they want a full copy of a file? What happens if another user makes a copy of the file and alters it? Are both copies changed? "The replacement decision will be based on original file and folder ownership, an…

> This might be a deal-breaker for some users. Why not just ask the user if they want a replacement versus a full copy? Shortcut preserves semantics: working on the original file or working on a shortcut to the original file will both modify the same document. Fully copy (create a new document with same contents as original document at a point in time) would bring new semantics.

It would also have quota implications - if I had a 5GB file multiparented in 3 locations, I wouldn't want to suddenly be over quota because Google decided I really wanted it copied to 3 locations.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#56

So, hard links are being replaced symbolic links. Most people I know prefer symlinks for most uses, so this feels like better UX.

What happens if you put a file in both the House Projects folder and the Current Projects folder, and then want to delete one of them?

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#57
post #32
post #3

I worked on the original (long since superseded) implementation of the metadata store for Google Drive, i.e. the system which was responsible for tracking file / folder relationships. The requirement to allow an item to appear in multiple locations was a huge complication, in part because of the way it interacted with permissions being inherited from a folder to the items in that folder. I imagine this change may be…

I worked on another sync client's representation of filesystem structure, and came to the same conclusion. Hard links enable some cool behavior, but in retrospect added more complexity than anyone expected. Migrating to shortcuts / soft links seems very reasonable - I wish I had started there.

What kinds of cool behavior do hard links enable?

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#58
post #57
post #32

Earlier quoted context omitted.

I worked on another sync client's representation of filesystem structure, and came to the same conclusion. Hard links enable some cool behavior, but in retrospect added more complexity than anyone expected. Migrating to shortcuts / soft links seems very reasonable - I wish I had started there.

What kinds of cool behavior do hard links enable?

Every file is essentially the master pointing at the same inode. So the file remains as long as any of the hard links exist. With soft links if you delete the master file all the soft links stop working.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#59
post #51
post #3

I worked on the original (long since superseded) implementation of the metadata store for Google Drive, i.e. the system which was responsible for tracking file / folder relationships. The requirement to allow an item to appear in multiple locations was a huge complication, in part because of the way it interacted with permissions being inherited from a folder to the items in that folder. I imagine this change may be…

Googler, opinions are my own. This was my understanding as well. The original Drive was built effectively as a directed graph (with cycles allowed). Any file or folder could be stored in multiple locations. And permissions were at a per-file basis, so 2 people viewing the same folder may see different sets of files. And permissions were definitely a hard part of it, as if you applied new permissions to a folder and a…

Forgive my ignorance (and there's a lot of it), but navigating a graph and setting permissions doesn't seem like a terribly difficult problem, especially for Google - the king of graphs, in a word. I would think maybe the issue has to do with how permissions of a file/folder apply to different users, but then isn't that just exactly the raison d'etre of permission systems?

This isn't an area I'm qualified to have a technical opinion on but if you'd care to elaborate I'd be interested to learn more.

Re: Google Drive: Shortcuts replacing files and folders stored in multiple locations

#60
post #51

Earlier quoted context omitted.

Googler, opinions are my own. This was my understanding as well. The original Drive was built effectively as a directed graph (with cycles allowed). Any file or folder could be stored in multiple locations. And permissions were at a per-file basis, so 2 people viewing the same folder may see different sets of files. And permissions were definitely a hard part of it, as if you applied new permissions to a folder and a…

Forgive my ignorance (and there's a lot of it), but navigating a graph and setting permissions doesn't seem like a terribly difficult problem, especially for Google - the king of graphs, in a word. I would think maybe the issue has to do with how permissions of a file/folder apply to different users, but then isn't that just exactly the raison d'etre of permission systems? This isn't an area I'm qualified to have a t…

Googler opinions are my own. I've never worked on Drive.

It's not hard, but expensive.

If you have a file system where it is a proper tree in any given node within that tree only has One parent, and walking up all the parents you always only have one parent up to the root node, you gain some useful properties from that. You can build a permission model where you just have to check the permissions of all of your parents to see if someone has access to a given file deep within the system. This means that if you Grant Reed access on any node within that line of parents, all children implicitly get access.

Now imagine a directed graph, and you set permission on a node and you want to say all connected nodes also should get this permission. You could definitely walk all the nodes and apply that permission, but now you have to write said permission to every node, rather than being able to set it on a parent and let all children inherit it. Even if you know all of your parents, then all of those nodes have multiple parents. And you can have cycles. Checking parents for permissions becomes way more complicated for users to understand, which is why Drive likely didn't do this.

Post reply on HN