Other Files disappear after reboot on NTFS partition

eternal_noob

eternal_noob

I have a dual boot system with FreeBSD 13.0 and Linux. There is a shared partition with the NTFS filesystem.

I can read and write from Linux just fine.

Reading works from FreeBSD, but written files disappear when i restart the computer. They are not persistent. What can i do?

/boot/loader.conf:
Code: 
fusefs_load="YES"

/etc/fstab:
Code: 
/dev/ada0p6    /mnt/shared    ntfs mountprog=/usr/local/bin/ntfs-3g,rw,uid=1001,gid=1001,dmask=027,fmask=137,locale=de_DE.utf8  0 0
uid=1001 and gid=1001 are the ids of the user i am logged in with.

mount | grep shared
Code: 
/dev/fuse on /mnt/shared (fusefs)

Code: 
[xxx@xxx /mnt/shared]$ touch test.txt
[xxx@xxx /mnt/shared]$ ls test.txt
test.txt

# REBOOT

[xxx@xxx /mnt/shared]$ ls test.txt
ls: test.txt: No such file or directory

Any advice?
 
I found a bug report with the same problem: PR 194526
This gave me the idea to unmount the NTFS partition before rebooting and it worked! The files were existent after the reboot.

The bug was opened 2014 so is this considered normal behaviour?
 
Do you fully shut down one system before booting into the other?

This kind of behavior happens all the time if you just hibernate or sleep a system: the OS usually holds changes in cache, without committing them to disk. If you don't shut the system down, the only copy of some change (such as a recently created file) may only exist in cache. Similarly, when you start an OS without a full boot (for example from itself being hibernated), it believes that its cache is still correct, and doesn't look on disk.

To fix this, always shut each OS down fully before starting the other one; that guarantees that all changes are flushed to disk. The same can be accomplished by always unmounting the shared file system fully.

In some cases, disabling caches works. But it doesn't always, because some caching is inherent in an operation of a file system.
 
That's unfortunate. So what you're telling me is this sequence:
  1. Boot FreeBSD, which mounts NTFS using FUSE, for example on /foo
  2. Create file /foo/bar/blatz in NTFS
  3. Shutdown FreeBSD cleanly with shutdown
  4. Reboot FreeBSD
leads to the file /foo/bar/blatz not existing after reboot? That's a bug. Note that I didn't have some other OS mess with the file system between steps 3 and 4.

That's a bit surprising. While reverse-engineered (blackbox or greybox) implementations of proprietary or ill-understood file systems, and FUSE file systems always cause me to be suspicious, NTFS-3g should be working better than that; it's old enough that simple caching bugs should have been fixed. Suggestion: Find the minimal scenario that can reproduce this bug, and bring it up on the developer mailing list.
 
ralphbsz said:
That's unfortunate. So what you're telling me is this sequence:
  1. Boot FreeBSD, which mounts NTFS using FUSE, for example on /foo
  2. Create file /foo/bar/blatz in NTFS
  3. Shutdown FreeBSD cleanly with shutdown
  4. Reboot FreeBSD
leads to the file /foo/bar/blatz not existing after reboot?
Click to expand...
Yeah, that is what's happening.

ralphbsz said:
That's a bug.
Click to expand...
Thought so.

ralphbsz said:
Suggestion: Find the minimal scenario that can reproduce this bug, and bring it up on the developer mailing list.
Click to expand...
If i had time, i would do so but i rather choose another filesystem instead.
 
eternal_noob is dataloss reproducible if you build and install fusefs-ntfs with UBLIO off? <https://www.freshports.org/sysutils/fusefs-ntfs/#config>

FYI FreeBSD bug 206978 – sysutils/fusefs-ntfs: Disable UBLIO as it breaks mkntfs

Cross-reference:

forums.freebsd.org

Other - NTFS doesn't unmount cleanly on shutdown

I have an NTFS partition that's mounted in fstab like so: /dev/nvd0p5 /windows ntfs mountprog=/usr/local/bin/ntfs-3g,rw,failok,fmask=113,dmask=002 0 0 When I modify a file on the partition and reboot (with shutdown -r now say) into either Windows or FreeBSD, then...
forums.freebsd.org forums.freebsd.org
 
For me, this is not a problem anymore because i currently don't own NTFS formatted disks.
In addition, compiling this stuff on my Raspberry would take ages, so no option either.
 
Microsoft

ct85711 said:
The question would be more of, is this really a bug or some intended feature by NTFS dev's (aka Microsoft)... I have never heard it has ever changed; in that the owner's/the actual devs of NTFS has ever supported that filesystem on anything but on Windows only.
Click to expand...

Microsoft support aside …

devel/libublio

The port to FreeBSD is explicitly not thread safe, but there's no reported bug.

As far as I can tell, the code originated in 2006 <https://web.archive.org/web/20070126153102/http://mercurial.creo.hu/repos/libublio>. Comparable UBLIO support on Mac OS X might have begun a couple of years later; see the foot of <https://forums.freebsd.org/posts/549566>. Loosely speaking:
  • code for UBLIO has been around for a long time; its use is widespread.

sysutils/fusefs-ntfs and NTFS-3G

ct85711 said:
The thing is, fuse NTFS is making assumptions on how NTFS works (they don't have access to the actual NTFS code). What is saying, that they are based off NTFS from pre Windows 2k; and not the version that windows 10/11 is using? As one thing that Microsoft changed in windows 8+ (it may have also been in 7 to a lesser extent) was what they referred to Fast Startup. Part of that "feature" is they changed how cached/dirty file state actually is handled; just like what how the filesystem is unmounted/mounted. That same "feature" has been causing numerous issues on non-Windows systems; as Microsoft has redefined internally what is clean mounted; which linux side never truly changed (since the change doesn't necessarily mean it has been noted in documentation). In the end, you are assuming this issue is a bug, but it can very well be an incompletely invalid reason, or the fuse-ntfs devs is considering it is a bug upstream of them and/or on NTFS it's self (which may very well be an intended functionality, but never mentioned).

Consider how long the issue is, chances are it's not a bug/they can't reproduce on their side or they consider this as some minor/edge case and have bigger fish to fry...
Click to expand...

Bug 194526 is reproducible without Windows.
 
You must log in or register to reply here.
Back
Top