Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtual-files feature on Owncloud client v2.6.0 with Qt 5.12.1 is missing completely #7027

Closed
lazawan opened this issue Feb 11, 2019 · 16 comments
Assignees
Labels
p2-high Escalation, on top of current planning, release blocker
Milestone

Comments

@lazawan
Copy link

lazawan commented Feb 11, 2019

simply VFS is not there :-`( " i mean on all linux Platforms )

regards,

@ogoffart
Copy link
Contributor

It is!

Maybe you are using a branding that disable it?

@lazawan
Copy link
Author

lazawan commented Feb 14, 2019

@ogoffart no i used the daily build for 2.6.0 client , i'm aware that branded-client doesn't have VFS

@ckamm ckamm self-assigned this Feb 14, 2019
@ckamm ckamm added this to the 2.6.0 milestone Feb 14, 2019
@ckamm
Copy link
Contributor

ckamm commented Feb 14, 2019

Maybe the client can't open any of the vfs plugins. @lazawan Could you give me the first 20 lines of the client log file? It should say "VFS windows plugin is available" and "VFS suffix plugin is available". Also look for "owncloudsync_vfs_*.dll" in your install directory.

@jnweiger
Copy link
Contributor

jnweiger commented Feb 14, 2019

Same here: owncloud-client 2.6.0 daily 20190211 on Linux Mint, Ubuntu 18.04

  • The firstrun wizard no longer mentions any expermimental features.
  • The three dots menu no longer allows switching to/from virtual mode.
  • renaming a file to end in .owncloud just renames the file. It is uploaded to the server with this suffix.

Is there now a VFS plugin that is needed for Linux? Maybe packagaging needs to adapt for structural changes?

@ckamm
Copy link
Contributor

ckamm commented Feb 14, 2019

@jnweiger Yes, a plugin is necessary for suffix-vfs now. Does the package contain the libowncloudsync_vfs_* shared library? @dschmidt

@jnweiger
Copy link
Contributor

No. Packaging cannot pick up new additions. I need to locate everything manually. Thanks for the hint, I have to ho searching now..

@jnweiger jnweiger self-assigned this Feb 26, 2019
@ckamm
Copy link
Contributor

ckamm commented Feb 26, 2019

@jnweiger The plugin is called "owncloudsync_vfs_suffix.so" built from "src/libsync/vfs/suffix" and should be installed next to the binary. I imagine linux packaging will not like that latter part. I'll check out what paths QPluginLoader looks at.

EDIT: Primarily it uses dlopen, so next to the other shared libraries should work. If it needs a "lib" prefix, we could adjust that.

@jnweiger
Copy link
Contributor

DEB packages have it in the build-log
[ 368s] [ 21%] Linking CXX shared library ../../../../bin/owncloudsync_vfs_suffix.so
[ 1182s] -- Installing: /usr/src/packages/BUILD/debian/tmp/opt/ownCloud/ownCloud/lib/x86_64-linux-gnu/plugins/owncloudsync_vfs_suffix.so

but it neither breaks packages with "unpackaged file error", nor is it auto-included anywhere. That is odd.

@jnweiger
Copy link
Contributor

jnweiger commented Feb 27, 2019

Is there a simple test to see where the plugin is searched at runtime?
should e.g. strace owncloudcmd -v show something?

Next to the other libs, with or without a plugins subdirectory, with or without a lib* prefix -> it does not seem to work.

@jnweiger
Copy link
Contributor

jnweiger commented Feb 27, 2019

It gets loaded, if placed next to the binaries in

ll /opt/ownCloud/ownCloud/bin/
insgesamt 2604
drwxr-xr-x 2 root root    4096 Feb 27 10:34 ./
drwxr-xr-x 4 root root    4096 Feb 11 16:48 ../
-rwxr-xr-x 1 root root 2541848 Feb 27 09:59 owncloud*
-rwxr-xr-x 1 root root   84216 Feb 27 09:59 owncloudcmd*
-rw-r--r-- 1 root root   26776 Feb 27 10:34 owncloudsync_vfs_suffix.so

Alternatively I can place it in $QTDIR/plugins/, which is also somewhat wrong, as it belongs to owncloud, not to Qt.

@ckamm that is a mess. We should try to make it work from the libs/plugins folder where libowncloudsync and friends are. I tried setting CMAKE_PLUGIN_INSTALL_DIR, but it has no effect, except that cmake complains this variable is ignored.

@jnweiger jnweiger removed their assignment Feb 27, 2019
@jnweiger
Copy link
Contributor

@guruz guruz added the p2-high Escalation, on top of current planning, release blocker label Mar 4, 2019
@ckamm
Copy link
Contributor

ckamm commented Mar 6, 2019

Huh, dlopen() should be using the normal search path for shared libraries, so it should be found among the other libraries that the executable's RPATH points to. I'll install it and check it out, the LD_DEBUG environment variable should be helpful.

@ckamm
Copy link
Contributor

ckamm commented Mar 6, 2019

Qt manually resolves plugin paths and uses dlopen only with absolute filenames. I agree that our plugin doesn't belong into the Qt/plugins directory and assume distribution packagers would also be unhappy putting them there.

I propose we add a build setting for a path that we add to Qt's plugin search path on startup and then place our plugins there.

ckamm added a commit that referenced this issue Mar 7, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 11, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 12, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 13, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 13, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 13, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
ckamm added a commit that referenced this issue Mar 14, 2019
By default, plugins are only searched next to the binary or next to the
other Qt plugins. This optional build variable allows another path to be
configured.

The idea is that on linux the oC packaging probably wants the binary in
something like /opt/owncloud/bin and the plugins in
/opt/owncloud/lib/plugins.

Similarly, distribution packagers probably don't want the plugins next
to the binary or next to the other Qt plugins. This flag allows them to
configure another path that the executable will look in.
@ckamm
Copy link
Contributor

ckamm commented Mar 14, 2019

@jnweiger Now that this is in the workaround should not be necessary any more. Either set the new PLUGINDIR path, or install to the place it points to by default.

Btw, I tested http://download.opensuse.org/repositories/isv:/ownCloud:/desktop:/daily:/master/Ubuntu_18.04/ and didn't get the plugin installed (with the symlink workaround).

@ckamm ckamm removed their assignment Mar 14, 2019
@jnweiger
Copy link
Contributor

jnweiger commented Mar 22, 2019

Linux builds seem to install the vfs_suffix plugin now into

  • DEB: @CLIENT_ROOT@/lib/$(DEB_HOST_MULTIARCH)/@APPLICATION_SHORTNAME@/plugins/
  • RPM: @CLIENT_ROOT@/%{_lib}/@APPLICATION_SHORTNAME@/plugins/

Examples:

  • DEB
    ** /opt/ownCloud/ownCloud/lib/x86_64-linux-gnu/ownCloud/plugins/owncloudsync_vfs_suffix.so
    ** /opt/ownCloud/testpilotcloud/lib/x86_64-linux-gnu/testpilotcloud/plugins/testpilotcloudsync_vfs_suffix.so

  • RPM
    ** /opt/ownCloud/ownCloud/lib64/ownCloud/plugins/owncloudsync_vfs_suffix.so
    ** /opt/ownCloud/testpilotcloud/lib64/testpilotcloud/plugins/testpilotcloudsync_vfs_suffix.so

I am changing the *.install, *.rules *.spec files to pick it up from there.

@jnweiger
Copy link
Contributor

tested 2.6.0daily20190322 on ubuntu-18.04 using Qt-5.12.2

The plugin is there
-rw-r--r-- 1 root root 26776 Mär 22 17:53 /opt/ownCloud/ownCloud/lib/x86_64-linux-gnu/ownCloud/plugins/owncloudsync_vfs_suffix.so

and works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2-high Escalation, on top of current planning, release blocker
Projects
None yet
Development

No branches or pull requests

5 participants