Live data from Hacker News

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

support.google.com

1–10 of 74 posts

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

#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 motivated by a desire to move away from that complex model, and whatever team owns that system now may be very happy to see it going away.

(IIRC, the requirement stemmed from the need to support the various applications that were being folded into / integrated with Google Drive, such as Photos which of course allows a photo to appear in multiple albums.)

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

#4
I think this is a good move – the cloning UX experience was a nightmare. I've moved many shared files to Team Drives because the language is easier for most of understand.

I imagine this was a tough call for a PM, with a lot of cases to consider and account for given this is so embedded in the Drive product DNA.

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

#5
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…

> various applications that were being folded into / integrated with Google Drive

The Photos/Drive integration was removed a long time ago. What other integrations were behind the original requirement? I'm curious to know if the extra complication was worth it in the long run and how long the integrations that needed this feature hung around for.

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

#6
What happens to a file if post-replacement the file is modified? Does it modify the link target, or is it copy-on-write?

I might want to have different copies as "snapshot" and "working", de-duping them makes any version-control-like system mutable, doesn't it?

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

#8
"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, and will also consider access and activity on all other folders to ensure the least possible disruption for collaboration."

"You can’t opt-out of the replacement."

This might be a deal-breaker for some users. Why not just ask the user if they want a replacement versus a full copy?

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

#9
post #5
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…

> various applications that were being folded into / integrated with Google Drive The Photos/Drive integration was removed a long time ago. What other integrations were behind the original requirement? I'm curious to know if the extra complication was worth it in the long run and how long the integrations that needed this feature hung around for.

I don't specifically remember whether there were other motivations for that requirement. Possibly a desire to support "tag" style interfaces, where an item can have multiple tags applied. But it may have mostly been the Photos integration.

And no, definitely the complication was not worth it in the long run. :-) That project got way more complicated than anyone wanted (not that there's anything unusual about that).

Post reply on HN