Created attachment 145401 [details] A file stored on SP with earlier version If we edit a file stored on a SharePoint 2010 server in LO 6.1, it deletes all the earlier versions of the file that were automatically saved. LO 5.4 saved a new version of the file, while 6.0 had a problem with saving to SP at all, so it's hard to bisect this one. We still see this on the current bibisect-win32-6.2 repo, so still present after fixing bug #119238 Version: 6.2.0.0.alpha0+ Build ID: 75a48e37b260c145297261d0e0ab5720894404f1 CPU threads: 4; OS: Windows 6.3; UI render: GL; Locale: hu-HU (hu_HU); Calc: CL
Created attachment 145402 [details] After saving the same file with LO master Screenshots were made last week, but the problem is still present.
Added bibisectRequest. Gabor, could you possibly bibisect it to find the guilty commit? your expectation that it may be related to bug 119238 look reasonable - I'd think the same - but the fix doesn't make difference, so it's either a different problem, or we need to revisit the fix. I didn't repro this yet, so can't set it to NEW; but as our rules say, if you bisect this, then you can put it to NEW yourself.
How does LO access SP, is it mapped to a driver letter (i.e. mostly transparent to us), or it's explicit in some way?
(In reply to Miklos Vajna from comment #3) > How does LO access SP, is it mapped to a driver letter (i.e. mostly > transparent to us), or it's explicit in some way? Way I tried is to use as UNC path like \\hostname\DavWWWRoot\places\projectname\Shared Documents Have not tried by opening from web UI due to permission issues on the local system :(.
(In reply to Gabor Kelemen from comment #4) > Way I tried is to use as UNC path like > \\hostname\DavWWWRoot\places\projectname\Shared Documents So this was transparent possibly - but I have a vague memory of some fix I made to deduce underlying redirector based on the UNC... possibly something to do in this case, either. > Have not tried by opening from web UI due to permission issues on the local > system :(. Well - didn't get this. What is the issue here? do you mean that you can't reguster URL handlers when installing? then you could try to create a command line like `soffice https://path/to/file.doc` maybe? Or how permissions play role here in other ways? (asking to educate myself, please don't take offence here)
(In reply to Mike Kaganski from comment #2) > Added bibisectRequest. Gabor, could you possibly bibisect it to find the > guilty commit? your expectation that it may be related to bug 119238 look > reasonable - I'd think the same - but the fix doesn't make difference, so > it's either a different problem, or we need to revisit the fix. We tried to bibisect with bibisect-win32-6.1, this is the result: # bad: [7ee9f0665bc96bcfa34506bef9b1569e6b368708] source 22c451df33b733440f24c1feb6380d31240d55e6 # good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 git bisect start 'origin/master' 'oldest' # good: [c0dc3e12b2b5f3047c02ed9cfe2f54e3fd663273] source fa2a43c29051b1bdcd0aef2e9cebfd206a4448ce git bisect good c0dc3e12b2b5f3047c02ed9cfe2f54e3fd663273 # good: [aa9ee79da17464e0558d7b73ef63e1e14c5ba342] source cc7ff0c141e27090ab521073b961b5eeeb4d693e git bisect good aa9ee79da17464e0558d7b73ef63e1e14c5ba342 # bad: [3a91a0eac74a6f94ea2ec5b69edf16658be818f2] source c4380ced324877a91a6df5db938c70ab53a257a1 git bisect bad 3a91a0eac74a6f94ea2ec5b69edf16658be818f2 # bad: [c329ce0207b27fca59767250b821a986269aadc4] source e87ea03a0d595ed478f281a723a6889228babeb2 git bisect bad c329ce0207b27fca59767250b821a986269aadc4 # bad: [e167d258e60bd93f679c9bee530a71026e84b873] source 73584b2342b4e527b5329b4bf779171c4fc2d4ce git bisect bad e167d258e60bd93f679c9bee530a71026e84b873 # good: [59b56d152bf84e20e4920156235efd07c29f279f] source 3564b46992fc30e212011c19043a2553178ccbca git bisect good 59b56d152bf84e20e4920156235efd07c29f279f # bad: [f05bff378d797c4a7756d5afd24957dff6076f3a] source 84854917835b13851d4855fa5eb30036a38b9166 git bisect bad f05bff378d797c4a7756d5afd24957dff6076f3a # good: [415b59d370d5f6f7206cead6282a3021edc96132] source cb06f61967850f7c3bbaaf3575901d6a18b94c96 git bisect good 415b59d370d5f6f7206cead6282a3021edc96132 # good: [402261c7a51179ce0dad912f8a8bc13e15d66e3c] source d2799676584b51f66721717b69a5604cf4a65af8 git bisect good 402261c7a51179ce0dad912f8a8bc13e15d66e3c # bad: [dcbd270ea85fcf0e8200173920ba14e73a6d87fd] source 02e5ff1d9b12c12fcaaa929c6dea626eefc5bb8c git bisect bad dcbd270ea85fcf0e8200173920ba14e73a6d87fd # bad: [dfac264c22b92910f335912ebd67e23ae64c29f0] source 642a49e8d3006d000bc6c58def34d4e96764c6cc git bisect bad dfac264c22b92910f335912ebd67e23ae64c29f0 # good: [5c832bc2dea41cbda669a77971d5a69f2b186261] source 773191d76d0c4a01f52a670018d505e86441407d git bisect good 5c832bc2dea41cbda669a77971d5a69f2b186261 # good: [0b51d3583f896a4023435da050bd21c98cacd469] source 6f45e696874401a224fa6c3c6b299933b3ae793f git bisect good 0b51d3583f896a4023435da050bd21c98cacd469 # first bad commit: [dfac264c22b92910f335912ebd67e23ae64c29f0] source 642a49e8d3006d000bc6c58def34d4e96764c6cc https://cgit.freedesktop.org/libreoffice/core/commit/?id=642a49e8d3006d000bc6c58def34d4e96764c6cc In other words, when saving to SP was fixed in bug #116420 this was already broken. Maybe by something earlier than that, but I can't really verify. I tried the latest version in bibisect-win32-5.4 too, this did work correctly, a new file version was saved: Version: 5.4.5.0.0+ Build ID: 534fd9aacd3eea10070a3ee88fc654eb9791aa24 CPU threads: 4; OS: Windows 6.29; UI render: default; Locale: hu-HU (hu_HU); Calc: CL
(In reply to Gabor Kelemen from comment #6) > ... > git bisect good 5c832bc2dea41cbda669a77971d5a69f2b186261 > # good: [0b51d3583f896a4023435da050bd21c98cacd469] source > 6f45e696874401a224fa6c3c6b299933b3ae793f > git bisect good 0b51d3583f896a4023435da050bd21c98cacd469 > # first bad commit: [dfac264c22b92910f335912ebd67e23ae64c29f0] source > 642a49e8d3006d000bc6c58def34d4e96764c6cc > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=642a49e8d3006d000bc6c58def34d4e96764c6cc > > In other words, when saving to SP was fixed in bug #116420 this was already > broken. Maybe by something earlier than that, but I can't really verify. So it means that you marked "good" the versions that failed with lockfile problems, so you couldn't really verify those? Could you please checkout cab3468e96552348ae46121a490f1f6160b65213, (the one before 6ca3b3648e25ae9d4d2d29a0df83349198ec3f5e which was fixed in 642a49e8d3006d000bc6c58def34d4e96764c6cc) and test if it's ok or bad there? That was in 6.0, and you need to find relevant bibisect commit using git log --grep cab3468e96552348ae46121a490f1f6160b65213
The commit to bug #121288 fixes this too. The commit before it still deletes earlier copies of the file. *** This bug has been marked as a duplicate of bug 121288 ***