Quota not updated after moving files to shared folder in webinterface. #21236

Closed
Bubu opened this Issue Dec 16, 2015 · 12 comments

Projects

None yet

5 participants

@Bubu
Bubu commented Dec 16, 2015

Owncloud: 8.2.1 (stable)
System: Debian 7.9
php: 5.4.45-0+deb7u2
php5-redis: 2.2.5-1~bpo70+1
redis-server: 2:2.4.14-1
apache: 2.2.22-13+deb7u6
mysql: 5.5.46-0+deb7u1

Config excerpt:

  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0,
  ),
  'theme' => '',
  'maintenance' => true,
  'asset-pipeline.enabled' => true,
  'log_rotate_size' => 104857600,

What I did:
A user had no space left on his account, so he moved a bigger file (1GB) to a folder shared by another user though the web interface.

Expected behaviour:
Now the file should not count against that user's quota anyumore and he should be able to upload new files.

Actual behaviour:
The 1 GB still counted against the users quota and he was not able to upload new files.

Workaround:
Manually triggering a rescan through the occ console command fixed the wrong space usage calculation. The user can now upload new files.

@MorrisJobke
Member
@PVince81 PVince81 added this to the 9.0-current milestone Dec 17, 2015
@PVince81
Collaborator

@Bubu we need your ownCloud version

@icewind1991 size propagation issue maybe ?

@Bubu
Bubu commented Dec 17, 2015

Sorry, the OC Version must have been lost to copy&paste. updated the post: v8.2.1 (stable)

@Bubu
Bubu commented Dec 17, 2015

I did a few more tests. Suppose we have the following Structure of files:

OCRoot
--Shared_Folder
--File1
--File2

File1 gets moved to Shared_Folder.

  • If I delete File1 afterwards (from the client in this case) the quota still gets not updated.
  • If I remove File2 the free space gets recalculated correctly, including the change for File1
  • The same problem also happens when moving the file in the client, not through the web interface
@cmonteroluque cmonteroluque modified the milestone: 9.1-next, 9.0-current Feb 22, 2016
@PVince81
Collaborator

Still happening on v8.2.5.

It looks like cross-storage move isn't triggering a size update in the database.
@icewind1991 potential regression.

This works properly in 9.0.2, possibly because etag + size propagation has been rewritten in a different way.

@PVince81 PVince81 added sev2-high and removed sev4-low labels Jun 14, 2016
@PVince81
Collaborator
PVince81 commented Jun 14, 2016 edited

Also broken in 8.0.8 v8.1.8

@PVince81
Collaborator

Works fine in v8.0.13.

Initiating bisect sequence

@PVince81
Collaborator

So, I did a bisect and only observed the Webdav property "quota-available-bytes".
Before this commit d7b3a1a, moving a file into a received share would properly update the "quota-available-bytes" value. After this commit, the value stays unchanged.

However I also observed that the other property "quota-used-bytes" was not always updated, so this will need another bisect...

@PVince81 PVince81 added the regression label Jun 14, 2016
@PVince81
Collaborator

Okay, regarding "quota-used-bytes" it's another topic. It might be a valid value and includes the size of files used in received shared folders. So it might be correct.

I'll check the oc_filecache entries instead.

@PVince81
Collaborator

Bisect result: after the same commit d7b3a1a doesn't properly update the size of the "files" entry in the database after doing a cross-storage move.

@PVince81
Collaborator

@felixboehm FYI
For OC < 9.0 any unexplained insufficient space issue could be related to this one.

@icewind1991
Member
icewind1991 commented Jun 14, 2016 edited

Fix is here #25101

@PVince81 PVince81 closed this Jun 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment