Symlinks

[hxss]

Do you guys planning to add support of symlinks?

[Andrew15-5]

As a developer, the most basic "temporary" solution is to add a set of switches to cover all behaviors of the megasync. By switches, I mean checkboxes (or, like in mobile OSes — literal switches). This is to enable full support ASAP. But if the future version will incorporate only one true solution, then it will bring breaking changes for some users.

Not thinking too deep, I think at least one switch must be present: "upload symbolic links"/"dereference all symbolic links before uploading". There are situations when symlinks will not point to other thing that is in the cloud but to some local stuff (that are out of sync dir). In this case, the best solution is to copy a dereferenced file/directory to the cloud but don't change the local symlink. Because storing (mixed|hybrid|with metadata) files/dirs would probably be a huge pain (but I can be wrong).

But the ultimate solution will probably have additional metadata stored (where necessary) with file/dir. Such metadata will tell the megasync client how to handle each symlink. Using the previous example: if there is a local path that is present in the additional metadata, then symlink will automatically point to that path. If it isn't present, then paste symlink as a regular file/dir. And for such trick to work, the app must know how to make symlinks on different platforms. And for the metadata to be saved in the local sync dir there should be a hidden dir/file with all the necessary "data" that track this metadata. For this Yandex.Disk (would) use .sync dir and MEGA — .debris (and that is for Unix-like OSes).

If devs can implement such metadata handling, then it should solve all the problems, I think, and therefore providing to users a magically perfect working-with-all-symlinks cross-platform cloud syncing client which will be one of a kind.

[VD171]

Hi there. Let's see if I can clarify something: We currently don't support symlinks. They are ignored by our sync engine. There might have been some issues in past versions with symlinks partially followed (e.g: Ubuntu's 14.04 version, which don't receive upgrades anymore. We will probably issue a new version for Ubuntu 14.04 for the next release, but an OS update is recommended).

You can, however, use a folder symlink to set the local folder when you establish a synchronization (it will sync the target folder).

Supporting POSIX symlinks is in the roadmap. The support we are aiming at (at least initially) is to treat them as symlinks. Don't following them. If you syncup a symlink, when synced down it'll be a symlink, pointing to the same target. Thus, you can recreate your local structure.

Hello, we want to upload a symlink and then download as it is, a symlink.

[eugenesvk]

• should it sync the symlink itself, or pretend the symlink target is part of the tree

symlink itself unless the user indicated the opposite

• would we receive filesystem notifications for changes in the symlink target (almost certainly not - and may vary across OS etc, and so you would not get a proper sync anyway)

the links could be periodically checked? Or at least warning re. this limitation could be added if that's too complicated. At the same time many symlinks are stable

• what if the symlink target is also inside the sync tree? Depending on choices you would end up with two copies of that subtree in the cloud

this could be warrant a warning (or if it's intentional, not a big deal? the user currently can already store copies)

but you're right,

Yes, there are a lot of complications with symlinks

[mattw-mega]

Syncing the symlinks themselves (not the linked article) as symlinks seems to be the way to go, it makes logical sense and doesn't have any particular issues - except that, the MEGA cloud filesystem doesn't have a representation for symlinks yet (there have been occasional discussions on this topic though - I will bring it up again).

[AlexMartin17]

Symlinks doesn't seem to work on MEGASync 5.x either.

EDIT: For some reason, ignore button won't work either.

[onlycparra]

Feb 2024, still no support for symlinks. We just need you to put "that thing" in the cloud, and that's it. If we, locally interpret it as a link (valid or not) or as a donuts, that's our deal, not yours.

[VD171]

For sure, I will not renew my mega account. I need one-way sync for some folders I want to have an "exact backup". I need symlinks for my whole ext4 partition. Sad...

[Andrew15-5]

At the very least, we can choose one option and try it out. Then people will be able to actually use it and give useful feedback about what is great about the current implementation of symlinks and what needs an improvement. Some progress, even if it's not ideal, is better than no progress at all.

I still avoid fully embracing MEGA just because I don't want to sort my stuff to "things that have or could have symlinks" and "things that don't need symlinks". I don't want to keep a thought of "will it sync thing X to the cloud?" at the back of my head at all times.

[rautamiekka]

Syncing the symlinks themselves (not the linked article) as symlinks seems to be the way to go, it makes logical sense and doesn't have any particular issues - except that, the MEGA cloud filesystem doesn't have a representation for symlinks yet (there have been occasional discussions on this topic though - I will bring it up again).

MEGA can use any kinda representation to convert from/into an actual {hard,sym}link, it's so simple.

^ Hell, back in the old days, the links used to be just text files with the full target file path in it, so it'd be an extremely simple thing to implement.

[repsorp]

7 years later...

[onlycparra]

Symlinks, people, please!!