[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: https://github.com/nextcloud/desktop/pull/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 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?

[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 https://github.com/nextcloud/desktop/issues/3244#issuecomment-830190844.

[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 https://github.com/nextcloud/desktop/pull/3057

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

[wlnx]

@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.

[vgdh]

And it is a major bug.

[vgdh]

It is not expected behavior from file synchronization software.

[sagitariozod]

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.

[ACiDGRiM]

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.

[jdunn0]

@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.

[biva]

@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:

1. lnk and vfs are not compatible for now, because of technical issues
2. Without vfs, you can sync lnk
3. Users have proven than lnk files should be considered as normal files and be "syncable"
4. 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?

[CombeeMike]

@biva I don't think that there's a way for the user to "opt out" of vfs and "re-activate" *.lnk synchronisation but I might be wrong 🤷‍♂️.

From here:

...

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.

...

2. Without vfs, you can sync lnk

...

IMHO everything you said sounds true except the 2 statements above.

If I'm wrong: Could you explain how I could achieve this (where to deactivate vfs etc.)?

[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.

No it doesn't. Look and sorry my russian:

Windows: I can cat the lnk-file to terminal, even if it is bound to directory

z:\tmp\RR>type test.lnk
L☺¶☻└F(cOБОж╫☺╝гчВОж╫☺(cOБОж╫☺☺☺¶▼PрO╨ ъ:i►в+00Э↓/Z:\J1∟S╜Шtmp8 ♦я╛ШJ;д*Soо.o!☺V☺tmp↕H1╕RIдRR6  ♦я╛╕RНб*S=Ю.ФФ
ПаБRR↕N1*Sсоtest:       ♦я╛*Sсо*Sсо.х7☺
z:\tmp\RR>type test
Отказано в доступе.

Linux: I can cat neither directory nor symlink to it, because symlink is a special file system object:

~$ ls -ald test*
drwxr-xr-x 2 lynx lynx 4096 Sep 11 01:00 test
lrwxrwxrwx 1 lynx lynx    4 Sep 11 01:00 test.lnk -> test

~$ cat test.lnk
cat: test.lnk: Is a directory

~$ cat test
cat: test: Is a directory

Thus, lnk-files are just blobs that are handled in some way by Windows shell "explorer.exe", even cmd or powershell have nothing to do with them.

[wlnx]

Windows did not support symlinks before Windows Vista

Being honest it did. NTFS supported symlinks from Win2000, but symlinking was hidden. In Vista we met mklink utility not to dive into fsutil or something more interesting.

[wlnx]

@biva I don't think that there's a way for the user to "opt out" of vfs and "re-activate" *.lnk synchronisation but I might be wrong 🤷‍♂️.

From here:

... 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. ...

2. Without vfs, you can sync lnk

...

IMHO everything you said sounds true except the 2 statements above.

If I'm wrong: Could you explain how I could achieve this (where to deactivate vfs etc.)?

I can explain. Just use NextCloud client 3.1.3. It disables vfs and enables lnk.

[jdunn0]

@wlnx said

Being honest it did. NTFS supported symlinks from Win2000, but symlinking was hidden. In Vista we met mklink utility not to dive into fsutil or something more interesting.

Windows 2000 and Windows XP had support for NTFS Junctions, not symlinks. Junctions could be linked to another folder on the same drive or a different drive with an absolute path but with symlinks you could do relative links to folders, links to UNC paths and links to files.

[wlnx]

@wlnx said

Being honest it did. NTFS supported symlinks from Win2000, but symlinking was hidden. In Vista we met mklink utility not to dive into fsutil or something more interesting.

Windows 2000 and Windows XP had support for NTFS Junctions, not symlinks. Junctions could be linked to another folder on the same drive or a different drive with an absolute path but with symlinks you could do relative links to folders, links to UNC paths and links to files.

I ain't ready to setup XP back to check if I'm missing something, thus let it be. It's been a long time ago. =^>.<^=

[jdunn0]

I ain't ready to setup XP back to check if I'm missing something, thus let it be. It's been a long time ago. =^>.<^=

You don't need to setup Windows XP to check as on Microsoft's official documentation on Symlinks it says "Symbolic links are available in NTFS starting with Windows Vista".

[wlnx]

I ain't ready to setup XP back to check if I'm missing something, thus let it be. It's been a long time ago. =^>.<^=

You don't need to setup Windows XP to check as on Microsoft's official documentation on Symlinks it says "Symbolic links are available in NTFS starting with Windows Vista".

Well, let's begin docufighting: From NTFS 3.1 onwards, symbolic links can be created for any kind of file system object. NTFS 3.1 was introduced together with Windows XP ... Since Windows XP uses the same NTFS format version as later releases, it's feasible to enable symbolic links support in it. For using NTFS symbolic links under Windows 2000 and XP, a third-party driver exists that does it by installing itself as a file system filter.

I don't think the holywar makes any sense here. Anyway, symlinks and lnk-files are not the same. We all say hello to QT.

[jdunn0]

@wlnx It's not a holywar, I was just pointing that there was no built-in support for Symlinks in Windows 2000 and Windows XP. The third-party driver didn't even exist until many years after the release of Windows Vista. Windows 2000 and Windows XP did have support for Junctions but to create them you needed a third-party tool like Sysinternals Junction.

The entire point of my first point in this topic was just that symlinks and .lnks are not the same. Qt has been around for a very long time, it may have done the treat .lnk files as symlinks before Windows 2000 even existed so there was likely no Junctions or Symlinks available when that was done.

[wlnx]

@wlnx It's not a holywar, I was just pointing that there was no built-in support for Symlinks in Windows 2000 and Windows XP. The third-party driver didn't even exist until many years after the release of Windows Vista. Windows 2000 and Windows XP did have support for Junctions but to create them you needed a third-party tool like Sysinternals Junction.

The entire point of my first point in this topic was just that symlinks and .lnks are not the same. Qt has been around for a very long time, it may have done the treat .lnk files as symlinks before Windows 2000 even existed so there was likely no Junctions or Symlinks available when that was done.

What is "built-in"? FS had full support of symlinks starting with XP (2000 had only junction points, yes). Usermode - yeah, had none. We finished at the start point: before Vista symlinks were available - but only with 3-rd party drivers. Vista brought us usermode and mklink. And Win10 made non-privileged users able to use the functionality. And Qt does strange things.

And no matter what point Qt uses to treat lnk-files as symlinks. The files are not and have never been.

[jdunn0]

What is "built-in"? FS had full support of symlinks starting with XP (2000 had only junction points, yes). Usermode - yeah, had none. We finished at the start point: before Vista symlinks were available - but only with 3-rd party drivers. Vista brought us usermode and mklink. And Win10 made non-privileged users able to use the functionality. And Qt does strange things.

Despite the File System having the capability of symlinks, because Windows XP had no included driver for handling them or APIs for creating them, it wasn't a built-in feature of the OS. I would say that built-in would refer to things the OS can not do on it's own without third-party drivers. I can see how this can be interpreted differently though so I guess agree to disagree here.

Back on topic, I tried downloading the OwnCloud Desktop Client and found that it does support syncing .lnk files with Virtual File Support enabled which was a bit of a surprise as I would have thought that both clients would have the same issue as they both have a lot of code in common.

[wlnx]

What is "built-in"? FS had full support of symlinks starting with XP (2000 had only junction points, yes). Usermode - yeah, had none. We finished at the start point: before Vista symlinks were available - but only with 3-rd party drivers. Vista brought us usermode and mklink. And Win10 made non-privileged users able to use the functionality. And Qt does strange things.

Despite the File System having the capability of symlinks, because Windows XP had no included driver for handling them or APIs for creating them, it wasn't a built-in feature of the OS. I would say that built-in would refer to things the OS can not do on it's own without third-party drivers. I can see how this can be interpreted differently though so I guess agree to disagree here.

Back on topic, I tried downloading the OwnCloud Desktop Client and found that it does support syncing .lnk files with Virtual File Support enabled which was a bit of a surprise as I would have thought that both clients would have the same issue as they both have a lot of code in common.

Ah, I misunderstood you, sorry. Ok, I agree, despite XP had the capability, interaction with it was a very strange magic, thus being unavaiilable for the most of users.

OwnCloud doesn't meet the issue? xD Maybe it has sense to move from NextCloud.

[Temtaime]

@wlnx hello. I'm currently working on custom desktop client that will for sure sync .lnk files. And be faster than current one. :) Stay tuned

[ScarUY]

@wlnx hello. I'm currently working on custom desktop client that will for sure sync .lnk files. And be faster than current one. :) Stay tuned

I'd like to know more! I do need those .lnk files! (currently I'm trying to keep my company's workflow with batch scripts, it's making me hate my life) My team is starting to regret nextcloud and want to go back to owncloud, please help me disuade them, bring back the lnk!

[doctorscott]

I have to say that this is a very unfortunate situation. While I very much appreciate the developers' efforts and the utility of this software, this change is in direct conflict with the ethos of this software. We are supposed to be able to setup and control our own cloud file server. I am very disappointed with this unilateral decision.

On a windows machine, broken lnk files are not dangerous. Yes, it is possible to create symbolic links (both soft and hard links!), but lnk shortcuts are not the same thing. I can see no valid argument above that makes any sense for blocking lnk files. Again, these are very, very different from symbolic links. They are just files. Are you also blocking .url files? It seems not... It is really easy to set url files up to link to local files/folders by using the "file" url (e.g. file:///C:/Users/). This is the exact same thing as lnk files.

Why not have an option in settings to allow for lnk files? Even disable it by default?

I lost a bunch of really useful lnk files when this occurred and am pretty frustrated. Guess I'll just set them up as url files instead. But that is silly... Sorry to shame the developers (I really, really like this product!). But this is very bad form on their part...

[bdrewery]

They are just files

Fact. Which makes "No, we don't plan to sync the .lnk files again" strange. It is disappointing that the devs here cannot admit a mistake. The decision is clearly based on the wrong assumptions. That the files are expected to act like symlinks. But that's not what is being asked here at all. We just want our files synced. But then we are told "nextcloud is not a backup system" just to cover themselves. Fair statement but not a fair policy to reject fixing what amounts to an arbitrary file extension not being synced.

There may be QT behavior that needs to change but reading through the QT source it appears trivial to add some kind of global override for the behavior, assuming that the API is being used correctly here in the first place. Whether QT maintainers will take such a change I don't know, but someone needs to try. It's not worth trying with the current policy and attitudes here.

Seriously the attitudes are just pushing away users and potential contributors.

[biva]

Thanks all for your comments, showing the strong interest of the community to be able to sync lnk files again on Windows. @allexzander mentioned that this needs QT6.2. This version has been released end of September, but I guess Nextcloud needs time to work on its integration.

Waiting for that, @allexzander @FlexW may I ask you to reopen this ticket, as this issue is not solved yet, and I understand (with thanks ;) ), that it's not a "won't fix" issue?

[FlexW]

I admit that I made a mistake when saying that lnk files are like sym links. I didn't know it better at the time. Still, the problem is that the way the Qt file API is designed will lead to deadlocks when using virtual files on Windows with lnk files with the current desktop client architecture. There have been internal discussions about this problem. Some developers suggested doing the hydration process in separate threads to work around that limitations. Others suggested just creating a special utility function for this case. The multithreaded approach will require quite some work and testing but might be the cleaner solution. Adding utility functions, for now, might be more pragmatic. Currently, this task is not scheduled for any developer and I'm sure if one of you submits a pr with a good solution it will get accepted. So I encourage you to make one :)

[AtomicWerks]

I would like to add that as a control systems engineer, this has caused me to lose work in the past. Siemens S7-300 plc programs use .lnk files in a couple places of the directory structure and when working collaboratively, the projects became unreadable by the Siemens Simatic Manager (development environment).

Since realizing that this bug was the cause of the issue, I've since moved to a different platform for controls projects specifically. With that said, I would still very much like to have my working directories fully synced to my Nextcloud server for redundancy.

Please consider reopening this ticket and resolving the issue.

[biva]

Hello, if this issue is creating problems in an atomic factory ☢️, then we have big troubles 😅.

Thanks @AtomicWerks for your report. To avoid misunderstanding, this ticket is still open. I guess nobody from the community nor from Nextcloud had the time/capability to solve it yet.

@FlexW I understand that you're considering a "special utility function for this case". I agree that it would be an easier way to go, even if less clean. Just to have an idea, would it be possible to share if Nextcloud moved to QT6.2? And if you're still planning to solve this issue at some point?

Thanks!