Static Share Links

Any plans to keep share links static? Right now if you change the file either by web GUI or via sync the share link stops working. So if you create a document share it, go back and make an alteration to it (replace a word/etc.), the share link stops working. So they then have to resend a new link, so now the user has two link one that doesn’t work and the good one. If they continue to negotiate/ and the document changes they must then send another link and so on, sometimes these documents change five or six times per client, you can see how managing ever changing links can become very cumbersome.

The company does now want to create users for every single person that they negotiate with sometimes (100+ Clients per day).

They want to be able to upload a file and be able to change it and even after it has been changed the link still works so the client can continue to access it. This is where Dropbox shines, the share links continue to work even after document changes.

3 Likes

Which version do you use? Share links still work for me after updating the shared file (tested with community version 5.1.3). I like that too, but I do know that other solution (for example Filr from Novell) go the other way and disable share links after the contents changed (or that’s at least my experience in our company).

@Robbie
I would suggest to share a folder with files in it. So that files can change names and stay available under the same link. I know, it is not the same, but maybe it helps.
I’m not quite sure, if it is possible/can be easily implemented to preserve the share link by following a renamed file. I have no knowledge about how renaming is handled in databases, etc.

@Simsala
Updating a shared file works with persistent share link, but as far as I know the renaming of a file will “break” the share link.

ah yes that’s correct, I thought it’s about changes IN the document.

Sorry yes when we update a file we edit the name to reflect that so file.doc upon revision will then be labeled file rev2.doc and so on…

@Nytrm Our current folder/file structure.

Company>Year>First Line Supervisor>Region>Second Line Supervisor>Division>Third Line Supervisor> Sub division>Department>Subdepartment (If needed)> Full/Part Time> Employee> Employee only files/ Employee and super files/ Supervisor Files for that employee.

So you can see the files structure is already intensive, If I start adding folders to share then that would add about three more levels, some files only the employee has access, some files only the supervisor has access to for each employee under him/ and some files both super and employee have access too. We have started to implement this on some clients, and it works but for others it does not especially when HIPPA is concerned, simply because if someone gains access to that share link and password they then have access to all the private info contained in that folder verses by sharing only the file if a link and password is lost/etc then only that document is compromised and not everything inside the folder.

Hm, I see your dilemma. Static share links would be really an option for you. I’m interested in how easy/difficult/impossible it would be to implement this feature!

@daniel.pan, @lins05 - Is this even possible?

I summaries the discussions as

  • If you share a folder, the rename of files in this folder will keep the link
  • If you share a file, the rename of the file will not keep the link.
  • Changing the file content will keep the link.

Changing file content should not affect the link. Can you try again?

Sorry forgot to edit my original post, but what is needed is when a file is renamed the link still remains good.

So when a file is shared a link is created, once the file is edited the append a revision to it, so the file goes from file.doc to file rev1.doc which breaks the share link, and has to be re shared and if another edit needs to happen it then goes from file rev1.doc to file rev2.doc, which breaks the link again. Dropbox handles these name changes somehow I’m just not sure if its possible in your current implementation.

It is possible if the file is renamed via web interface. For file renamed via syncing, it is much complicated to implement.

That works it’s better than nothing they will have to just start using the web GUI over the file system, maybe a little further down the road you can revisit via the sync method (When your looking for a good challenge.)

I know it’s hard to change a long time ago established procedure, but one (easy and fast solution) could be to leave the name for the current version the same and rename the old versions.

1 Like

I’m not sure I am understanding there is no old version that same document gets edited and renamed every time.
Care to explain what you mean, I maybe reading to deep into this…

Good Idea @Simsala : Always the newest version “name.odt” shared by link, and after a revision is made, name the file “name.odt” to “name_YYYYMMDD.odt” and put new file “name.odt” in same place as old one. So newest version is always available under the same link.