desktop
desktop copied to clipboard
nextcloud
[3.2.1 regression] Shortcut .lnk files cannot be synced anymore
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?
Actually, I confirmed it: previous versions allowed to sync .lnk files. Is it possible to solve that? [edit: lnk, not lst]
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: https://github.com/nextcloud/desktop/pull/3057
@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 https://github.com/nextcloud/desktop/pull/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?
@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.
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?
@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.
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?
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?
@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.
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.
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.
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 :)
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.
@Temtaime It has been explained already why this can not be done. There is a comment in the issue you've just reopened https://github.com/nextcloud/desktop/issues/3244#issuecomment-830190844.
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.
@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.
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.
@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.
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.
@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.
@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.
@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 https://github.com/nextcloud/desktop/pull/3057
I think this issue should be re-opened, as it is valid as reported.
@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.
No doubt this issue is from Qt. I just try to say this is bug, not feature.
I also want to sync LNK files. It would be great! I understand that an .lnk file contains data, it is not the same as a symbolic link, that it is dependent on the operating system, and therefore it should just sync and I should be able to choose whether or not it syncs. If the problem is QT, perhaps an alternative would have to be considered, although I suppose it would take a lot of effort, but if its use involves restrictions that prevent the user's total freedom to synchronize any type of file that contains data, this should be considered very seriously. change. My opinion is that something is being done wrong in the desktop client, and I have many years of experience as a computer technician, in fact currently in linux I use the owncloud client because it works better than nextcloud, my server of course has nextcloud installed. On the other hand, the size of the desktop client installation has become too large, 200mb, for the functionality it has to offer, in my opinion. I just installed google drive, which I haven't used for a long time, install size 60mb and it syncs lnk files perfectly.
Sorry, my English is very bad.
This is a useful feature. At my employer we use OneDrive and the users' desktop, including their .lnk files, are sync'd to their cloud storage. The benefit to users is that when the move to a new computer and login to a fresh profile, all they have to do is sign into the sync client (in this case Nextcloud Desktop) and their desktop shortcuts are available to them.
In my Nextcloud environment, I redirect the common folders, desktop/documents/Pictures/etc..., to the NextCloud folder via GPO folder redirection, and we do this with OneDrive users. This way on login all of the paths are pointing to the sync folder, and waiting for the user to simply login so their files start appearing. It works great!
At least in OneDrive, we do not have issues with .lnk files syncing, even if they point to a local application, a non-existent path, or even a network resource. The concern about .lnk files syncing to Linux or Mac clients could be mitigated by setting those files in the Ignored list on those platforms, and excluding it on windows platforms.
Furthermore, windows users can make the same kind of FS shortcuts linux can in the form of Junctions (limited to non-admin users) which are not sync'd for obvious reasons. This should have no bearing on .lnk sync on windows clients.
@FlexW said
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.
You are incorrect about .lnk files being the same symlinks.
As someone else mentioned .lnk files are the same as .desktop files on *nix systems. They are regular files which the Windows Shell or a Desktop Environment understands and does something with like launching an app or open a folder specified in the file. Symlinks as entries in a file system that point to a file to folder which are transparently followed by any application on the system.
Windows did not support symlinks before Windows Vista and that is probably why things like Qt used .lnk in place of them but that is not their purpose.
The files .lnk, .desktop along with others like .url serve a different purpose then symlinks and should be treated as the regular files they are and synced like any other file.
If you need to wait until the client is upgraded to use a newer Qt version first then I guess do that but at that point there would be no reason to not allow .lnk syncing again.
@jdunn0 thanks for your input. I think that the Nextcloud team is doing its best to solve this issue, and I understand that it is somehow planned for this year, as @allexzander shared in https://github.com/nextcloud/desktop/pull/3057#issuecomment-885433569
At some point (could be even this year), we plan to approach this problem from another perspective and bring back .lnk files synchronization.
As far as I understood, you can sync lnk if you don't use vfs. If you want to use vfs and lnk together, like me, we'll have to wait.
I think the Nextcloud team initially didn't see the significant number of valid use cases that a lot of people have with lnk files. These examples have been shared several times here, or in https://github.com/nextcloud/desktop/issues/3499 and in https://github.com/nextcloud/desktop/pull/3057 . I think that it has been accepted by the Nextcloud team as a regression that should be fixed.
To summarise, I think the current situation is:
- lnk and vfs are not compatible for now, because of technical issues
- Without vfs, you can sync lnk
- Users have proven than lnk files should be considered as normal files and be "syncable"
- The Nextcloud team has a lot of priorities and work, and is doing its best to solve this issue this year
Am I correct? In any case, I think this issue should remain open somewhere, either reopen this one, or merge with https://github.com/nextcloud/desktop/pull/3057 to avoid duplicates. @allexzander and @FlexW would you consider that?