We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Best practices for using symlinks (symbolic links)
Hi there,
I use dropbox on linux with symlinks, but am not sure which is the best/preferred way to use them. Is there a best practice for using this type of configuration?
Currently I use symlinks in my home directory that point to the actual folders in my Dropbox folder, but I have heard of doing the inverse: placing symlinks in the dropbox folder pointing out into the home directory. Are there pros and cons to symlinking from the Dropbox folder to the home directory vs. placing a symlink in the home folder linking to inside the Dropbox folder?
What happens during a catastrophic failure triggering a need for data restoration, which method is preferred? Is there a way to dynamically create links for new entries (like .* folders)? Is there an advantage/disadvantage to using soft vs. hard linking?
Any links/posts with regards to the above would be most appreciated. I acknowledge that Dropbox does not fully support symbolic links, but find them so useful I am committed to using them.
Thanks in advance!
- Daphne
Dropbox Staff
Reality check here. a) I use a symlink to include my Desktop accross multiple devices. b) I'm NOT moving my Desktop in the 'Dropbox' folder. Th systems require it to be right where it belongs.
So I guess it's Good Bye after many years of what was a great service.
Agree with AnotherAnon,
I also use symlinks to have all my devices Desktops available on the cloud. I cannot move my Desktops folders to dropbox folder.
What a stupid change by part of Dropbox! If Dropbox do not remediate this soon i will also say goodbye to Dropbox....
This sounds like an edge case, as plenty of users used symlinks the old way without the high CPU or missing file issue. Using ~/Dropbox as the working directory does not fit all use cases. Dropbox as a backup solution has been completely broken with the decision not to support symlinks. Dropbox could fix this by having a selective backup option in the mac app (not selective sync, selective backup), but as it stands now, Dropbox is now useless for me and all those that used it as a backup solution. This was a bad move on Dropbox's part and has forced me and others to seek out other providers.
- Agree, am in exact same boat - I have several things I want to keep backed up / off site, where the actual data directory can't be under my user profile / dropbox folder. Symlinks allowed this to work perfectly until blocked.
Hi Daphne,
Thanks for your response, sounds like sticking with the current setup definitely makes sense.
Also, while setting up dropbox on a live usb stick, I just discovered another reason for using symlinks pointing into the Dropbox folder. Doing the inverse would likely cause the data from each separate host to clobber the other host's data. With symlinks pointing the Dropbox folder I know have the same data across hosts that I want to share in common, which is pretty useful.
From what you describe, I guess as a best practice it would be advisable to not drop any symlinks into the Dropbox folder at all as it sounds pretty risky. I hope a better solution to dealing with symlinks is developed, but until then it sounds safe to avoid using them in any way within the Dropbox hierarchy structure.
Thanks for your help!
Before Dropbox changed it symbolic linking policy, I would add a symbolic link to my Dropbox folder. Dropbox would automatically upload a file whenever I added or changed it that folder. However, Dropbox has changed this feature. Therefore, I no longer need Dropbox. I can use OneDrive if I have to manually put my files in a separate folder to be synched.
Unfortunately, this has broken my use for Dropbox as well. I always understood it wasn't a supported option, but to completely remove it has also removed the usability of your product. Not a good way to treat your customers.
I will cancel my Dropbox abonnement immediately if this is really taking place in linux (I am not sure whether it happened right now, would be shocking for me). I do not know why those stupid companies break such valuable functionality all the time. I cannot move the files to the actual dropbox folders, because they are spread over six or seven different computers, on disks mounted with NFS, and some folders are mapped with symbolic links into the dropbox on my main Linux server, which is my cloud backup.
Alternatively, I could export the relevant folders individually with nfs and mount them into the Dropbox. Would this work? What would happen if a connection and thus the mount fails, and there is only the empty mount point? Would the data in the cloud be erased?
"High CPU use" is just a symptom for buggy programming, the symbolic links cannot impose a fundamental problem. It rather shows that Dropbox has lost it's interest to fully support Linux. I'm very disappointed with Dropbox. I think they will quit bussiness soon; they have lost their edge over the competitors.
I'm the OP and I marked this resolved b/c I wanted to know the best practices for using Dropbox with symlinks on Linux. Granted, as others have mentioned, it is not ideal, but I'd rather backup via a method that is blessed by Dropbox and not lose my data.
For those with multiple Desktops (or any other directory like Pictures, Music, Videos, etc) across different hosts, my solution has been to create separate host parent dirs with the relevant dirs to backup and then symlink from the host into this hierarchy. I agree it is not ideal, it seems like it would be a lot better to symlink from within Dropbox out to the folder, but Peter S.32 tangentially brings something up I had not thought of: if you symlink from within Dropbox out to a folder and that link gets broken, will Dropbox just zero out the data until the link gets fixed? That seems risky to me and I don't feel like testing it, so I'm sticking with my setup.
If anyone has moved on from Dropbox and cares to share their experience, please do post (thanks jsparks), thanks! I've been looking at a few other options as well since Dropbox seems to not be able to figure out how to backup iOS burst photos (they blame apple/iOS), but google photos has been able to for a while.
cheers
- Sorry, but you just quote a problem which I mention in my post. I suggest to read it again. Yet, I will discuss possible solutions:
If a mount or symlink breaks, the sync demon must handle that correctly. This means: no syncing action whatsoever in those folders, as if there was no internet connection at all. The other folders, however, should be synced as usual. Once the symlink or mount goes valid again, the folder should be rechecked and synced, as if I had worked offline. I think this is what the user expects, isn't it?
The question is how to achieve that. This is an entirely technical question, and Dropbox was always leading in robust syncing, so I think their engineers do not need my help here. However, as you ask, there are several possibilities:
1) The demon should remember and check whether a directory is a mount point, or a symbolic link, by using the information provided by the file system. If it is, it should be checked whether the connection is just down, or whether the user actively changed it (e.g. by replacing a symbolic link with a local directory or vice versa). If the user's purpose is clear, it should be respected. If the demon cannot figure it out, a "conflicting copy" of the folder should be created.
2) A hidden file in every directory, marking it as that which was actually synced, when and with what, will help the demon a lot in figuring out what should be done. If a mount fails, it will show up as an empty directory, without the marker file. It should be igored, but shown as "offline" in the Web-interface. If the user deletes the marker file, a "conflicting copy" of the whole folder could be created, if there are any binary differences of the files. The marker files also help if a file system does not show links and mounts properly, and will even help against circular hard links.
3) If everything failed (e.g. because of a "bug" in Windows with the purpose of tricking Dropbox into deleting files) there is still the possibility to recover lost files.
It is just a technical problem.
