If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#30
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|