File versioning doesn't work

[RandolfCarter]

Recently the versioning has completely stopped working for me. Not alone that I don't see any history anymore (as reported in this other issue: #101), there's also no new files created anymore in the "files_versions" or "versions" subdirectories of the user data folder ("files_versions" is the one actually used in 4.5, right, and "versions" can be removed, correct? Or are both used?). Versioning app is enabled, and the checkbox in the admin section is also checked. There are no errors in either owncloud or server log I could relate to this phenomenon.

I can not reliably link this problem to a specific upgrade; it could have started at either the 4.0.8 -> 4.5 upgrade or the 4.5. to 4.5.1a update.

See also this forum thread: http://forum.owncloud.org/viewtopic.php?f=3&t=4569 - It has some info on what I tested specifically (I tested both upload via client and web interface). If more info is needed I'd be glad to provide it.

I'm not 100% sure on the expected behavior here, but my expectation would be:
In the web interface, whenever I upload a file with the same name, and choose to overwrite the existing one, a new version gets created
Via the client, whenever I change a file, and this file is synced to the server, a new version is created
Whenever I edit a file (e.g. text file) on the server, and store it, a new version gets created

That's how I would expect versioning to work - and for me, none of the above works at the moment.

[DeepDiver1975]

Thanks a lot for this bug report - afaik we have already a fix for this issue.
@schiesbn Am I right? Is that related to your fix yesterday? THX
@karlitschek I'd consider this as a reason for a new bugfix release - agreed? THX

[RandolfCarter]

sounds good :) anything I can test immediately, is it supposed to be fixed in git master?

[DeepDiver1975]

should be on the stable branch already - do you mind giving it a try? THX

[RandolfCarter]

I have to say I never tried using git master directly - is there some documentation on how to set it up for web access? I cloned apps, core and 3rdparty repositories in one folder "owncloud" and made the owncloud folder available via apache, but when I now access owncloud/core/, I only get an incomplete page - output stops abruptly at line 16 in a javascript:
var datepickerFormatDate =
There's no error in server log

[DeepDiver1975]

afaik - master is broken anyhow at the moment to some extent - use the stable45 branch.
as I said: I assume the fix has been backported to stanble45

[LukasReschke]

There's no error in server log

Even nothing in the PHP log?

Output stops abruptly at line 16 in a javascript: var datepickerFormatDate = ¨

This seems to be related to the issue i wanted to fix with 5245e2b introduced by a24d8db and 41b597e.

Any ideas here? - @tanghus Maybe? :-)

[RandolfCarter]

Ah ok, missed that, will try stable45 branch

[samtuke]

@LukasReschke @schiesbn make sure debugging mode is enabled if you're looking for errors in logs, otherwise they may not be saved anywhere (see https://github.com/owncloud/documentation/blob/master/developer_manual/debugging.rst)

[RandolfCarter]

Tried stable45 branch, and it seems to work; uploading in web interface now produces a new version for me!

I can't test the client at the moment, though, because I encountered another weird issue: I used a copy of my productive database but not my data directory (meaning fscache and filesystem were out of sync). After first server start, the clientsync directory was created; then on the server the clientsync directory showed up, with the content as in my productive environment (the files not being available of course, though). So I removed and recreated the clientsync directory (while the client was not running). Starting the client again it uploaded the one text file it had in its clientsync directory - and now it seems to be caught in an endless loop, saying over and over again that it can't find the files which never existed on the filesystem in the first place - and neither removing the fscache entries nor removing the csync cache manually (not much experience with the latter, maybe I didn't get the right one) seems to help. Amittedly, that's not a usual situation to be encountered, but a neverending loop is never good in my opinion. Any idea on how I can fix that? Should I create an issue for it?

If I have time tomorrow I will test the client with a clean DB.

[schiessle]

This is fixed in master and stable45 (also confirmed by @RandolfCarter). I agree with @DeepDiver1975, we should have a bug fix release soon.

@RandolfCarter Please open a new issue for the other bug report.