Windows is hibernating

Carlos E.R. wrote:
On 10/02/2019 05.54, T wrote:
On 2/9/19 6:53 PM, Carlos E.R. wrote:
On 09/02/2019 23.44, T wrote:
On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote:
In comp.os.linux.misc T wrote:
After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?
Are you mounting, in Linux, as ntfs or ntfs-3g?

The 'ntfs' Linux driver is read only.

The 'ntfs-3g' Linux driver is the read/write driver.

But, unless you ask mount to use ntfs-3g specifically, the
auto-detected default (at least on the one system I've got where I
mount an ntfs formatted USB drive [left as ntfs for compatibility with
a winblows system]) is 'ntfs'.
Depends on the distribution; for example on openSUSE the default is
ntfs-3g.

This is the only instance I have not been able to mount an NTFS
read/write with Fedora.

$ cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

$ rpm -qa ntfs\*
ntfs-3g-2017.3.23-8.fc29.x86_64
ntfsprogs-2017.3.23-8.fc29.x86_64
That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of
the kernel.

You have to issue "mount" to see how it is really mounted. Maybe it says
"fuse", then it is correct.

# mount -t ntfs /dev/sdc1 /mnt/MyCDs

# mount | grep /dev/sdc1
/dev/sdc1 on /mnt/MyCDs type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blks ize=4096)

Ok, that is ntfs-3g, mounted read/write apparently.

And then it's going to depend on where he attempts to write,
as to whether any weird errors show up. Don't do write
tests in WinSXS or System32, due to the landmines in there.
Test in /media/mount/Win10/users/username/Downloads or something.
As there shouldn't be any newstyle NTFS compression extended
attributes in there to screw things up. I had the file manager
(thunar or similar), stop painting the file list as soon
as it got an "I/O error" because of stuff like that. Any
decent file manager should behave exactly the same way.

The Paragon driver is a version of the fuse driver, where
Paragon has fixed only one of the three or so problems with
reparse points. I can't recommend that as a "panacea" for
the NTFS mess.

Fedora commented out the MFTMIRR problem in their distro,
something which Ubuntu hasn't done (yet).

The "hibernation problem" is not a bug, so don't expect
that to go away. You shouldn't be editing a hibernated
volume, due to the possibility there are still open
files on the volume from the hibernated session.
Doing a "clean" shutdown, is the recommended approach.

But nobody has reverse engineered these Reparse Points
enough, to fix the current limitations on Linux access
to Win10 C: drives. I've not heard of anyone attempting
to reverse engineer the reparse points, because if
the nitwits at Microsoft find out, they'll only change
the metadata on the next release. Since reparse points
are not standardized, there's really no reason to keep
anything about them constant from one release to another.

If Microsoft is doing this to make it impossible to "remove"
certain subsystems in a Win10 image, I'd say they're doing
a damn good job. I'm sure if one of the web sites interviewed
one of their developers, he'd tell us "we haven't a clue
what we're doing"... and I'd believe him.

Paul