You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Syncing a file <1Kb (827bytes) should sync its 827 bytes to the windows drive when I try to open it and it resides on the owncloud server (virtual files mode).
Actual behaviour
The local file becomes 0bytes. This is with virtual file support. So, when I try to open the file, which resides on the server and is smaller than 1KB (827 bytes in this case), it first is downloaded, but when I open it it is empty; and when I look it's 0 bytes. When I open it in the web interface, it is oke. When I sync a new file from local to server both files are the same size (client and server), but when I clean up the space and reopen it with e.g. notepad++ or notepad, the syncing starts, and next, notepad(++) is openened with an empty file. If I choose 'make available always', it will sync nicely and when I open the file, it contains the 827 bytes it had.
Steps to reproduce
Create a virtual files share.
Put a file of <1KB (827 bytes?) in it, a text file.
Make room, i.e. cleanup the files to the server
Open a file from the cloud by opening it with notepad.
Nothing will be shown.
Server configuration
Operating system: Debian 9
Web server: Apache 2.4, with Reverse proxy.
Database: PostgreSQL
PHP version: 7.2
ownCloud version: 10.5.0 stable
Storage backend (external storage): not applicable, just normal ext4 file system.
Client configuration
Client version: 2.7.1
Operating system: Windows 10
OS language: Dutch
Qt version used by client package (Linux only, see also Settings dialog): not applicable
Client package (From ownCloud or distro) (Linux only): not applicable
Installation path of client: Windows, standard
Logs
? Client or server? Let's just show what happens.
These are the files...
Making room...
It has been done...
Now double click on the item...and the result...
It starts having trouble...when I try to make it available always, it keeps syncing....When I make room on it, it puts it in the cloud again, and when I make it available always again, it hasn't been damaged, the file is there.
See attached files.
This is recorded while doing the above actions.
Expected behaviour
Syncing a file <1Kb (827bytes) should sync its 827 bytes to the windows drive when I try to open it and it resides on the owncloud server (virtual files mode).
Actual behaviour
The local file becomes 0bytes. This is with virtual file support. So, when I try to open the file, which resides on the server and is smaller than 1KB (827 bytes in this case), it first is downloaded, but when I open it it is empty; and when I look it's 0 bytes. When I open it in the web interface, it is oke. When I sync a new file from local to server both files are the same size (client and server), but when I clean up the space and reopen it with e.g. notepad++ or notepad, the syncing starts, and next, notepad(++) is openened with an empty file. If I choose 'make available always', it will sync nicely and when I open the file, it contains the 827 bytes it had.
Steps to reproduce
Server configuration
Operating system: Debian 9
Web server: Apache 2.4, with Reverse proxy.
Database: PostgreSQL
PHP version: 7.2
ownCloud version: 10.5.0 stable
Storage backend (external storage): not applicable, just normal ext4 file system.
Client configuration
Client version: 2.7.1
Operating system: Windows 10
OS language: Dutch
Qt version used by client package (Linux only, see also Settings dialog): not applicable
Client package (From ownCloud or distro) (Linux only): not applicable
Installation path of client: Windows, standard
Logs
? Client or server? Let's just show what happens.
These are the files...
Making room...
It has been done...
Now double click on the item...and the result...
It starts having trouble...when I try to make it available always, it keeps syncing....When I make room on it, it puts it in the cloud again, and when I make it available always again, it hasn't been damaged, the file is there.
This is recorded while doing the above actions.
OWNCLOUD probleem.zip
The text was updated successfully, but these errors were encountered: