If I create a new empty file on NTFS partition and then I reboot system with command "reboot" in Terminal, then after reboot new file is not exist on NTFS partition.
If I disable libublio support in NTFS-3G, then file is NOT losted.
If I manually unmount partition before reboot - file is NOT losted.
skuz@Desktop-PC:~ % pkg info | egrep "ublio|ntfs"
fusefs-ntfs-2014.2.15_2 Mount NTFS partitions (read/write) and disk images
libublio-20070103 User space caching library
skuz@Desktop-PC:~ % freebsd-version -ku
I am making an educated guess that the OP is talking about the unmaintained sysutils/fusefs-ntfs port, and changing the title accordingly.
Moving this PR to "open" since there's no one to assign it to and there's no patch to apply.
Add new maintainer to CC.
fusefs-ntfs has now 2017.3.23. I think this is overcome by events and could be closed.
(In reply to w.schwarzenfeld from comment #3)
No. Bug is still exists. I think that libublio do not flush a cache to disk with some interval (for example? every 1 seconds). This is brings to situation when small piece of last data always storage in memory.
Is this a duplicate of 206978 ? Could you try the patch from that bug?
(In reply to Alan Somers from comment #5)
What a patch did you mean? In the 206978 bug I see only patch for disable libublio, but in my first post I already talked that disabled libublio solves issue with losted files. But without libublio the performance is very poor.
koobs says that he wants to disable libuio due to "a number of bugs that have been reported for it". If libuio is going to go away, then this bug will go away too.
In the latest head, fusefs now has sane cacheing builtin. Can we eliminate libublio now?
(In reply to Sergey Kuzmichov from comment #6)
> I already talked that disabled libublio solves issue with lost files.
Another good reason to kill this option. Basically, because of it being enabled by default, we (FreeBSD) ship very broken package. This upsets our users and gives us bad image.
> But without libublio the performance is very poor.
Earlier this year, FUSE subsystem had seen a major update: the protocol
level was raised from 7.8 to 7.23, it fixed many bugs, and added many new features, have a look:
Sergey, could you reconduct your tests and see if performance issue persists?