client
client copied to clipboard
Opened files in virtual files system does not save when still open
Pre-submission Checks
- [X] I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
- [X] I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.
Feature description
On Windows when using VFS don't upload files while they are locked. This is due to the fact that we can't update the placeholder while it is locked and therefor the db and the vfs state can run out of sync.
Proposed solution
Upload the file anyhow, without updating the db or the placeholder. This will result in one additional upload once the file is closed but it should restore the upload of auto saves.
Alternative solutions you considered
No response
Additional context
No response
Update: We can't upload the file without out updating the db as the client would then detect a clash. We probably need to decouple the placeholder update from the update in the db.
New flow:
- Try update the placeholder
- Update the db, mark the placeholder as dirty if its update failed
- Try to update dirty placeholders ever X seconds
@TheOneRing can you port this bugfix as well to 2.10 branch?
No if it would be a simple fix I would directly implement on top of 2.10. It is not. Therfore it will be implemented in 4.0.
you sure it's only a problem when using ownclouds vfs implementation? I'm on full sync and experience the same behaviour as #9428. The problem should only occur when using vfs, shouldn't it?
I did some testing with an older version (2.8.1.4157)
2.8.1 with vfs enabled: MS: files saved but still open: error while writing meta data (different error) Non-MS: files saved but still open: works fine no error
2.8.1 with vfs disabled: MS: files saved but still open: will upload without error (desired behaviour) Non-MS: same
current with vfs enabled MS: file saved but still open: file is currently in use Non-MS: files saved but still open: works fine no error
current with vfs disabled same
Appearently office applications have an unique way to handle files (I've seen similar reports from onedrive users). Possible that current behaviour with full sync is the consequence of merging implementation to fix a different vfs problem?
It has nothing to do with office, but with how we handle locked files.
office aside (that was not my point), the problem also occurs with full sync, so the title is misleading. (I didn't understand and still don't why issue contains vfs (suggesting it only occurs with vfs) when neither of the previous bug reports use vfs). Appearently 'how we handle locked files' changed in >=2.8.1 to fix a vfs problem (meta data error?) and that fix creates the 'file is currenly in use' problem on the full sync side which it shouldn't (it worked before).
I'll track down the latest client version before that implementation and for the time being stay on that. Our environment went mental because sync was a mess. Users usually save files and don't exit the application but go to hibernation. Closing software has different drawbacks when using really big files.
nota bene: nextcloud current (we use both) gives 'file currently in use' when using vfs but no error when using full sync (desired behaviour).
I confirm what @stabledave reported: the issue with syncing locked files appears in version 2.9.2 also with plain non-VFS-enabled sync pairs.
As a matter of fact, I never realized it despite running 2.9.x for months, simply because the "sync issues" are all grouped together, including permanent issues (e.g. files in the ignore list or symlinks) that I regularly ignore (and I have now customized the filter to hide such cases, so that real issues do trigger my attention ;-) )
tested 2.9.2, 2.9.1, 2.9.0, they all have the 'file currently in use' problem. 2.8.2 seems fine (we use that for now) @glpatcern did you test 2.9.1?
I used 2.9.1 in the past, but can't confirm for sure this issue. Otherwise, I can confirm that 2.10.1 is also affected.
I am using the latest version(3.2.0) and experience the same problem that the files are not synching if it is open in Microsoft Office product. Is this problem still not fixed?
Fixed, but not released yet. You can test drive in the 4.0 pre-release builds:
- https://download.owncloud.com/desktop/ownCloud/daily/4.0/?sort=time&order=desc
You can install the testpilotcloud builds, to not mess-up with your production-ownCloud client:
- https://download.owncloud.com/desktop/testpilotcloud/daily/4.0/?sort=time&order=desc
Thanks for the info! May I ask when this 4.0 version will be released, approximately? To be on the safe side, I may just wait for the stable version, if it's coming in the near future.
May I ask when this 4.0 version will be released, approximately?
No ETA yet. Here you can find the open issues for 4.0:
- https://github.com/owncloud/client/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.0
thanks.
Please Test:
- [ ] Notepad++
- [ ] LibreOffice
- [ ] Microsoft Office 2019/2021
In version 4.0.0.10560-daily20230403
vfs enabled | vfs disabled | |
---|---|---|
Notepad++ | file synced when file is saved and application still open :heavy_check_mark: | file synced when file is saved and application still open :heavy_check_mark: |
LibreOffice writer | file synced when file is saved and application still open :heavy_check_mark: | file synced when file is saved and application still open :heavy_check_mark: |
@jnweiger will help with Microsoft Office 2019/2021
@michaelstingl Is this supposed to fix for https://github.com/owncloud/client/issues/8316 ? If so, I can use the reproducer steps there. Is testing against ownCloud-4.0.0.10639-beta1.x64.GPO.msi correct?
Confirmed fixed in 4.0.0-beta.2 Windows office save (and keep open) causes the client to sync the file to the server. OK.