Virtual Files on a Windows-PC that has Folder-Synchronization disabled

[BurninLeo]

The "virtual files" feature of OwnCloud works great, especially if there are a lot of files on the server, and you only need a few of them. First of all, thanks for that!

I recently tried the experimental "virtual files" feature on a PC that has the Windows feature "Offline File Synchronization" disabled. Company stuff, because that has caused trouble in the past when working with network drives....

This apparently affects how the "virtual files" of OwnCloud as displayed. As the client explicitly asks for feedback on the experimental feature, here we go :)

Expected behaviour

The files shall appear in the Windows Explorer as if they where there, with the original filename (filename.extension).

Actual behaviour

The replacement-files are displayed as filename.extension.owncloud, e.g., Sample.pdf.owncloud.

When right-clicking the file, and choosing ownCloud -> Download File from the contect menu, the file is retrieved correctly, and can be used. But, it is not auto-retrieved upon the first use.

Steps to reproduce

1. Disable the Window's Offline File Synchronization
2. Connect to a folder, using the experimental virtual files feature
3. Open the folder (or a subfolder of it) in the Windows Explorer

Server configuration

Operating system: Ubuntu 20.04 LTS

Web server: Nginx

Database: MySQL

PHP version: 7.x

ownCloud version: not relevant for this issue

Storage backend (external storage): Filesystem

Client configuration

Client version: 2.5.4

Operating system: Windows 10.0.18362

OS language: German

Installation path of client: default

[michaelstingl]

Please test with the latest 2.7.2 version:
https://owncloud.com/desktop-app/

Maybe you need to setup a new account.

[BurninLeo]

After updating to the latest version (2.7.3.2877), owncloud crashed - and kept crashing after reboot. Of course, not owncloud per se: After deleting the owncloud settings folder, and reinstalling owncloud it started correctly. But as soon as I tried to setup the sync folder with virtual files, it crashed, again.

After deleting the settings folder, and creating the "traditional" folder sync, everything worked fine. Therefore, I think we can assume that the "virtual files" feature does not yet work well with disabled "Offline File Synchronization".

[michaelstingl]

Did you submit the crash report? Please post the crash report ID. Thanks!

[BurninLeo]

Crash reports were submitted (2020-10-16 ~14:15 UTC), but I failed to note down the ID. I won't have access to the respective PC before January, but I can give it a try with the latest vrsion then, and report fresh crash IDs :)

[BurninLeo]

Just updated to version 2.7.5, crash still reproducable.

Here ist the latest crash report's ID:
26af14d3-95ed-402a-8ad3-2a98ba4ebd56

[TheOneRing]

I guess you deleted your sync root manually, please restore it or delete the %APPDATA%/ownCloud/owncloud.cfg

[BurninLeo]

I will try and report, but ... I installed owncloud without a root. Instead, I added the synchronization folders after the setup. One synchronization is working properly (not using virtual files), but as soon as I try to add another sync folder with virtual files, owncloud crashes. As said, I will try and report (but that will need a few days as I have no continuous access to that machine).

[BurninLeo]

Deleting the owncloud.cfg did not change the situation.

After closing owncloud, deleting the configuration file, and restarting owncloud, I was asked for the initial setup. I told the setup that I did not want to choose a folder immediately, but do that manually.

Then I added a new sync folder, selected an existing directory on my disk (actually a network-mapped drive!) and the respective folder on the owncloud server. And ... it crashed. Here's the crash report: d690dffa-f418-44af-9419-cd78319270b4

If I create a synchronization with virtual files disabled for the same folder, everything runs smooth.

[BurninLeo]

Okay, it seems that the network drive makes the difference.

I can create a synchronization to C:\Temp\boo but not to a mapped network drive H:\boo\boo

I selected a completely blank folder on the network drive in this case to make sure that the crash is not caused by pre-existing files.

Here's another crash report, just in case: 0e89417c-056b-42f8-a140-75c7dfc0642f in bug reports.

[michaelstingl]

Then I added a new sync folder, selected an existing directory on my disk (actually a network-mapped drive!) and the respective folder on the owncloud server. And ... it crashed. Here's the crash report: d690dffa-f418-44af-9419-cd78319270b4

VFS requires real NTFS, not a network drive. Desktop should check for NTFS when creating a new folder sync connection, so you can’t run into this issue. What exact steps did you perform?

[BurninLeo]

Desktop should check for NTFS when creating a new folder sync connection

There was no warning or anything else that would have stopped me from selecting the network drive. From what I see on the user interface, the owncloud client handles the C: and H: drive exactly the same when I try and create a sync folder.

What exact steps did you perform?

Only what I stated above: Created a sync folder by clicking the respective button in owncloud.

As I wrote in the beginning of this issue report, the Folder-Synchronization is disabled (via GPO) on the machine. Might that cause any failsafe mechanism not recognizing the H: drive als mapped network drive?

[TheOneRing]

Our network drive detection was broken.
Fixed in 2.8.2 and later

[jnweiger]

Re-testing with 2.8.2 on windows 10_H20_v2 in virtualbox, with a samba server (172.17.0.2) on same host

docker run --rm -v /home/samba:/shared -d --name samba dperson/samba -u "admin;admin" -u "Administrator;Passw0rd!" -s "shared;/shared;;no;;all" -n -p

The \172.17.0.2\shared drive is also mapped as drive letter Y:

Using the drive letter and using the \ network drive name produces different error messages, with and without subfolders.
The error messages are all different, (one of them looks truncated):

---

A local (non-network) drive: