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

monitor directories on cifs mount does not see remote copied files #10367

Open
jtmoon79 opened this Issue Mar 11, 2019 · 1 comment

Comments

Projects
None yet
1 participant
@jtmoon79
Copy link

jtmoon79 commented Mar 11, 2019

Repost from arvidn/libtorrent/issues/3703

qBittorrent version and Operating System

$ qbittorrent-nox --version
qBittorrent v4.1.5

$ uname -a
Linux host 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux

$ lsb_release -a
Description:    Raspbian GNU/Linux 9.8 (stretch)
Release:        9.8
Codename:       stretch

If on linux, libtorrent and Qt version

libtorrent 1.2.0 release
(headless)

What is the problem

qbittorrent-nox does not react to files added to a Monitor directory that is on a cifs mount.

What is the expected behavior

Processes the .torrent file, moves the file to the Copy .torrent files to path

Steps to reproduce

See arvidn/libtorrent/issues/3703

Extra info(if any)

@Chocobo1 wrote:

This is likely a problem in qbt, here you can see qbt tries to detect whether the path is pointing to a network mount, if it is then qbt will use the polling method:
https://github.com/qbittorrent/qBittorrent/blob/master/src/base/filesystemwatcher.cpp#L81

The function detecting the network mount:
https://github.com/qbittorrent/qBittorrent/blob/master/src/base/utils/fs.cpp#L345

The function scanning for new files:
https://github.com/qbittorrent/qBittorrent/blob/master/src/base/filesystemwatcher.cpp#L159

My guess the culprit is at Utils::Fs::isNetworkFileSystem probably it didn't match the magic number, or perhaps dir.entryList() in FileSystemWatcher::processTorrentsInDir didn't retrieve the files correctly (this would be an Qt issue).

Reviewing the mounted filesystem

$ mount -v
...
//nas/cifspath/monitor1 on /mnt/cifspath type cifs (rw,nosuid,nodev,noexec,relatime,vers=3.02,cache=strict,username=user1,domain=LOCAL,uid=1003,forceuid,gid=0,noforcegid,addr=192.168.1.10,file_mode=0755,dir_mode=0755,soft,nounix,serverino,nouser_xattr,mapposix,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=60)

$ stat --file-system --printf='(%i) filesytem ID in hex\n(%t) filesytem type in hex\n(%T) filesystem type in hrf' /mnt/cifspath/monitor1
(1a) filesytem ID in hex
(fffffffffe534d42) filesytem type in hex
(smb2) filesystem type in hrf

@jtmoon79

This comment has been minimized.

Copy link
Author

jtmoon79 commented Mar 11, 2019

It is very odd that 64-bit value fffffffffe534d42 is returned by stat as the filesytem type. I would expect 32-bit value fe534d42. Using stat version stat (GNU coreutils) 8.26. (I emailed bug-coreutils@gnu.org about the odd value fffffffffe534d42.)

I reviewed the /usr/include/linux/magic.h and value fffffffffe534d42 is not present. Nor is value 0xFE534D42.

Did I compile this qBittorrent wrong? The compile commands were

./configure --disable-gui --enable-systemd --with-boost-libdir=/usr/lib/arm-linux-gnueabihf
make
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.