BUG: 344146
Details
Details
Accessed a SMB share from Nautilus, chose "Open in other app", opened it with Dolphin, it would mount it to /run/user/foo/gvfs/bar.
I can now copy files over without getting a "disk full" error. However, after copy completes, I get a "cannot change permissions" error. It's a start, though... however, all those fields being zero could be valid? Imho the bug is in the GIO slave.
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
Quite fantastic. Can reproduce the initial problem, the fact that this fixes it, and the new permissions issue, which I can also confirm is fixed with D15154.
Comment Actions
It seems by adding gvfsd support for KMountPoint this has become obsolete.
$ df /run/user/1000/gvfs/ Filesystem 1K-blocks Used Available Use% Mounted on gvfsd-fuse 0 0 0 - /run/user/1000/gvfs
but the mount does report some free space
$ df /run/user/1000/gvfs/smb-share\:server\=localhost\,share\=smb1/ Filesystem 1K-blocks Used Available Use% Mounted on gvfsd-fuse 478636952 468610296 10026656 98% /run/user/1000/gvfs
gvfs uses a single fuse mount which then creates subdirectories for every mount.
KDiskFreeSpaceInfo checks the mountpoint, so it would always check the gvfs root directory which naturally doesn't have free space information available.
I will discard this patch now as it would just have hide a different bug.
Comment Actions
With a few modification the patch is correct and necessary though.
statfs (not statvfs!) has in the documentation: Fields that are undefined for a particular filesystem are set to 0.. Currently KIO just returns garbage in that case.
The KMountPoint calls above are not necessary with statvfs/statfs and in the gvfs case even hurt.
That it works now due to KMountPoint changes is just a side effect and a workaround, not a proper fix.