[3.2.1 regression] Shortcut .lnk files cannot be synced anymore

[biva]

I just installed 3.2.1 and I have the feeling that previously, .lnk files (shortcut in Windows) were synced (at least that I could remove these files from the Ignored Files list.

On 3.2.1, I can't force the sync anymore.

Am I wrong?

[biva]

Actually, I confirmed it: previous versions allowed to sync .lnk files. Is it possible to solve that? [edit: lnk, not lst]

[FlexW]

Yes, it was possible to sync these files in the past, but they caused trouble with the virtual files. Since the Nextcloud desktop client is intended to be used cross platform, we also try to not sync any platform dependent files, because they have no meaning on other platforms. For example it is not possible to use/create .lnk files on macOS or Linux. We also don't sync UNIX's symbolic links for the same reason.

Please have a look at the follwing pull request: #3057

[biva]

@FlexW Thanks for the explanation, I understand that virtual files create an additional issue. As @er-vin mentioned in a comment, as a user using .lnk files (only between Windows systems), I would have appreciated to see a warning before installing it (in the changelog for instance).

I also would like to better understand the issue mentioned in #3057: would it also happen if we sync files only between Windows systems? (only the server hosting Nextcloud is under Debian)

Also, is there a possibility to see this solved in the future? (to be able to sync last files again) In this case, shouldn't we leave this issue open?

[FlexW]

@biva Yes a warning would have been better. This can also cause issues when using Windows only. The problem are lnk files that point outside of the sync folder, because then Windows tries to download files that the desktop client can not provide.

[biva]

Thanks for your kind answer @FlexW
I read in your post that .lnk files will be treated as regular files (in a future version of Qt). Does it mean that we'll be able to sync .lnk files again? If yes, any idea of the timeline?

[FlexW]

@biva No, we don't plan to sync the .lnk files again and that's not bound to Qt. In my opinion it was a bug to even allow to sync these files in the past. We don't allow to sync UNIX's symbolic links as well for the same reasons. If we allow .lnk files, then we also should allow to sync symbolic links. If we want to do that in a proper way, we would need to make sure that .lnk files get replaced on UNIX systems with symbolic links and the other way round. To do this right, it would require a lot of work on the sync engine (and maybe the server). For now we want to focus on improving and stabilising the current sync engine and not introduce some new fancy feature that probably not enough people use to make it worth investing the time :) This might change in the future if a lot of people (especially paying customers) require that feature.

[biva]

What about for users who sync those files only on Windows? I really think it's a pity to not allow users to choose what they want to sync or not. I think that a good way would be to not sync these files by default to avoid issues, warn people about the consequences, and let users choose if they want to sync them or not.

We are syncing a lot of lnk files without any issues on 20 computers: your decision to remove this possibility puts us in a bad situation and we don't know how we'll reorganise some key processes.

If the issue you're mentioning is the same on 3.2 than on 3.1, and that having this possibility was just a mistake on 3.1, then we would like to have this mistake again in 3.2, as an option. Is it doable?

[FlexW]

The problem is also on Windows. The problem are .lnk files that point outside of the sync folder. Maybe we could discuss putting .lnk files into to the sync exclude list and then you could remove them from the exclude list and sync them. @allexzander @mgallien @camilasanI know we said it would be better to hardcode it in the code but what do you think?

[allexzander]

@FlexW @biva We can discuss the possibility to bring .lnk syncing back, but, only when the VFS is disabled. Otherwise, showing a warning for .lnk files with VFS turned on is simply not enough. The desktop client is simply freezing and is completely unusable when having the .lnk files enabled in VFS mode. @biva you can observe this issue if using the latest 3.2.0 RC 3 from here https://download.nextcloud.com/desktop/prereleases/Windows/ with VFS enabled. Severity-wise, it is way worse than simply ignoring .lnk files.

But yeah, we may consider allowing this for non-VFS mode. But, this may also bring a problem of inconsistent sync engine behavior between VFS and non-VFS modes.

[biva]

Hello @FlexW and @allexzander

Thank you very much for your effort to find a solution. I understand the technical issue behind your decision.

I think allowing this for non-VFS mode is already a good start: users know the risk and they will have to make manual action to allow it. I think nobody can complain if it leads to issues.

For VFS-mode, if I understand the future version of Qt's statement (".lnk files will be treated as regular files"), maybe you can allow it for windows users, when it will be possible with Qt?

For us, the VFS-mode is more interesting than the lnk management: we are in Africa and the bandwidth is expensive and slow. This is really useful for us to use VFS-mode. We'll wait for a solution for lnk with VFS.

[haniham]

I hope there will come a solution - so far i can't fix it by myself

I am using nx-cloud to backup files on my parents desktop so files with a big yellow exclamation point raise questions which turn to my problems for me. For me the easiest way would be that the link files keep on being synced as any other files, with the possibility for the ignore list,... . The link-follow is nice but unneeded for me. The problem is that the files are ignored without me being able to control them being ingnored.

And the rollback to older versions hasn't worked out quite well, so im in real need for a fix in future versions.

[ChrisBiesterveld]

Hi,

Landed on this page to find out why .lnk files where not synchronizing anymore and looked at the answers provided.

I do not understand the technical issue explained allexzander as it out of my expertise. Although the reasons could be very valid, from a user perspective hosting my own environment, I would like to have control over what I want to sync or not.

In general I would also appreciate to have the option to just use an exclusion list and not hardcode extensions to give that control back to the user (maybe only on server/admin level ?)

For now it would be sufficient for me if the .lnk files could be included again in the exclusion list.

Thanks :)

[Temtaime]

I think the issue should not be closed until the regression is fixed.
I don't see any reasons why lnk files cannot be synced even with vfs.
.lnk is an ordinary file, it is just treated differently by Windows, so there's no problem with having .lnk files in macos/linux.
Just sync it without any dereferencing.

[allexzander]

@Temtaime It has been explained already why this can not be done. There is a comment in the issue you've just reopened #3244 (comment).

[haniham]

But i want to sync the files as files and not follow them. It's a file like any other and thus is syncable.

Where do we come when owncloud decides to exclude more file extensions they don't like from sync in owncloud. That user paternalism is horrid.

[FlexW]

@haniham Please understand that the Windows system automatically follows the lnk files when using the virtual file system on Windows. Thats the problem and the desktop client can not prevent that Windows follows these lnk files when implicitly hydrating (downloading) files.

[ChrisBiesterveld]

But i want to sync the files as files and not follow them. It's a file like any other and thus is syncable.

Where do we come when owncloud decides to exclude more file extensions they don't like from sync in owncloud. That user paternalism is horrid.

I can copy lnk files from one system to another. Without any issues, even if the .lnk file points to something that does not exist. So I do get your response haniham.

I do not understand the "issue" described by FlexW, but that is mainly because I do not understand the technical issue described. If it causes problems for others then so be it, but I did request to have an option to determine it myself by putting it back in the exclusion list or maybe a new option on server level. For me Syncing .lnk files has never been a problem. Manually or via NextCloud.

So I do hope something will be created to get that functionality back and place the decision on what to sync back to the owner.

[Temtaime]

@allexzander i don't think that windows does anything regarding lnk files.
Linked PR in the comments states that there's QT api which follows lnk files on windows and it is deprecated. There must be other ways getting correct information.

[zlydk]

Please consider bringing .lnk syncing back.
My usecase: I sync (many) .lnk shortcuts to network resources across (windows) workstations using NC.
Maybe put .lnk files into to the sync exclude list by default, and let users make an active choice to remove it - with a warning or whatnot.

[vgdh]

I want syncing LNK files too.
It would be really cool!

[wlnx]

@haniham Please understand that the Windows system automatically follows the lnk files when using the virtual file system on Windows. Thats the problem and the desktop client can not prevent that Windows follows these lnk files when implicitly hydrating (downloading) files.

Maybe I've missed something, but OneDrive client syncs the files with no issue.
Furthermore, I cannot cd into, e. g., Windows.lnk => *.lnk files are not like symlinks that are not regular files at all.
Anyway, I also have file sets with lnk files. And if nextcloud knows what I want to sync better than me... Sad but true.

[allexzander]

@wlnx OneDrive is not using Qt. The problem is not in Windows .lnk files or Nextcloud, it's a problem with how the Qt versions prior to 6.x handles .lnk files on Windows. It is explained earlier in this thread.

[zlydk]

@wlnx OneDrive is not using Qt. The problem is not in Windows .lnk files or Nextcloud, it's a problem with how the Qt versions prior to 6.x handles .lnk files on Windows. It is explained earlier in this thread.

I think everyone agrees, that this problem originates in QT.
The question becomes whether Nextcloud is able (or willing) to look into a possible workaround for the .lnk handling issue in QT.
Some ideas was raised in #3057

I think this issue should be re-opened, as it is valid as reported.

[chylex]

This is an issue that only affects virtual file systems, right? If waiting for a QT fix and then upgrading QT is taking over a year, and the problem (from the users' perspective) is "Users who were not using VFS in the first place cannot sync .lnk files anymore", why can't the solution be allowing .lnk syncing as long as the user is not using VFS?

[pierre-pizzetta]

I also have users needing this feature, please bring .lnk files sync back. Like it was said before, those shortcuts are part of a lot of people workflow for efficiency. Thanks !

[mgallien]

I understand that this issue is important for quite a few people
this is why I started working again on it

first the changes we would need in Qt will probably happen only for the next major version (they tend to not do changes breaking existing code within a major release, so all Qt6 versions will probably keep the same behavior they have in Qt5)

that said, I tested again with other cloud file sync and share tools
as far as I can say .lnk are not handled like normal files but rather being always there (they can never be freed entirely)

and we could most probably apply the same solution (so .lnk file could be either always offline or downloaded but never online only)

[biva]

Thank you very much @mgallien to spend time on this :) I'm not sure to fully understand you:

• Do we need to wait for changes within Qt to do something? If yes, how can we push Qt to do the required changes?
• What do you mean by either always offline or downloaded but never online only?
  • I understand that we cannot apply "Free up local space" to this file, right?
  • What about if we "free up" the folder containing this file? The whole folder will be freed, except the lnk file which will remain locally, right? I think it's a very acceptable solution because these files are extremely light.

Does it require a lot of work to implement this solution?

Thank you again, sorry to not be able to help with the coding, but happy to test.

[julll190]

Hi,
I also need to sync several .lnk files, that is the main reason why I want to use Nextcloud on different computers, hope it will come back soon.
Thank you to accept to sync it again :)

[rexhunt]

Just dropping in to add my vote for this feature to return.
It sounds like it's more complicated than this, but an option to "treat .lnk files as regular files" would allow us to use Nextcloud within the Autodesk workflow that we've got.

Thank you for the work on this problem.

[n-aceves]

Hello, Please allow us to sync .lnk files again. Keeping it off by default but allowing us to have the option to enable the syncing of lnk files seems like the best solution.

Thanks.

[dinomueller]

I too need the syncing of .lnk files. I had several hundreds of them in my dropbox synced over several devices. Then I switched to Nextcloud and had to learn after client 3.2.1 it doesn't work anymore. So I had to go back to dropbox because of that, but I would like to return to Nextcloud again.

.lnk files are files! Not symlinks! I don't understand why you don't simply let us just sync them? They don't cause any problems on the server side.

[biva]

Yihaaaa! Congratulations @allexzander !! And thank you Nextcloud team

[ChrisBiesterveld]

Thanks for bringing the functionality back !
Could you let us know in what build it will be provided ? I updated to Version 3.6.0 (Windows) today, but lnk files are still ignored.

[allexzander]

Thanks for bringing the functionality back ! Could you let us know in what build it will be provided ? I updated to Version 3.6.0 (Windows) today, but lnk files are still ignored.

Will be released in 3.6.1

[n-aceves]

LFG. GOD BLESS YOU SIR. YOU JUST MADE MY LIFE TREMENDOUSLY BETTER.

I LOVE LNK FILES.

[mathew-cook]

Many thanks!

[Schniefel]

I am not entirely sure if this is fixed completely, as I have some .lnk-files which simply don't get synced with the desktop client. If I drag them in the web-ui the files get synced. So I assume there is a problem for the desktop client detecting some .lnk-files for syncing.

[Sieboldianus]

In the latest 3.15.0, it seems *.lnk files are not synced anymore. I get errors for all my shortcuts.

[RokeJulianLockhart]

#3244 (comment)

@Sieboldianus, got a log and/or screenshot of the errors?

[ChrisBiesterveld]

In the latest 3.15.0, it seems *.lnk files are not synced anymore. I get errors for all my shortcuts.

Fyi : Just did a test. I have 3.15 installed and everything seem to work fine.

[Sieboldianus]

I tested and I can create new .lnk files. This morning, all errors appeared with existing *.lnk files that could not be synced from remote. I deleted these and the errors were gone. I will report if my newly created lnk files today will be successfully synced on me 2nd laptop tomorrow!

[RokeJulianLockhart]

I tested and I can create new .lnk files. This morning, all errors appeared with existing *.lnk files that could not be synced from remote. I deleted these and the errors were gone.

@Sieboldianus, if you still retain those unsychronisable .lnk files in shell:RecycleBinFolder, try:

1. restoring one,
2. verifying that it's still unsychronisable,
3. creating a new one with the same parameters, and
4. verifying that the new one can be synchronized.

If it can be, then try diff-ing them to see what differs between them. If their file content doesn't differ, then it might be a bug with the "Files On-Demand" API (if you have NC's integration with it enabled).

[Sieboldianus]

I just verified on one of my computers that

• I can restore one of the *.lnk files (a folder) that failed syncing yesterday; it restored, is accessible (works), and I can delete it and create a new shortcut with the same parameters that syncs

For the file-shortcuts that failed on my other computer today, I will test tomorrow. But I have the feeling that it will be the same pattern.

Wait! The new lnk fails again:

Not that this error is with a newly created shortcut. I don't know how to diff it correctly - if I open the shortcut with nano from WSL, all I see is a blob of binary text.

[RokeJulianLockhart]

I don't know how to diff it correctly - if I open the shortcut with nano from WSL, all I see is a blob of binary text.

@Sieboldianus, apologies — forgot that the new .lnk files are binary. When created for more basic purposes, they can actually be valid .ini files (like their .URL counterparts always are).

[Sieboldianus]

Some more tests:

• I cannot create any lnk files (files or folder shortcuts) that do not produce these placeholder errors
• all lnk files are actually synced to the server, despite error

[dago666]

Same problem here.
*.lnk files are synchronized for the first time. But after client restart a sync error occur with 3.15.0.

After a downgrade to 3.14.0 it works again.