PCbanter - View Single Post

February 9th 19, 05:57 AM posted to alt.comp.os.windows-10,comp.os.linux.misc

On 2/8/19 9:06 PM, Paul wrote:
T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

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?

Many thanks,
-T

https://askubuntu.com/questions/7028...t-as-read-only

Â*Â* "The system might not have the files for writing to
Â*Â*Â* NTFS partitions installed.

Â*Â*Â* Try this in terminal:

Â*Â*Â*Â*Â*Â* sudo apt-get remove ntfsprogs && sudo apt-get install ntfs-3g

Â*Â*Â* This removes ntfsprogs if it's present on the system, and
Â*Â*Â* installs ntfs-3g which should allow you to write properly
Â*Â*Â* to NTFS partitions.

Â*Â*Â* Then reboot your system, and attempt to open the NTFS drive
Â*Â*Â* for write access. You should now be able to write to the
Â*Â*Â* NTFS drive.
Â*Â* "

Fedora is supposed to have an $MFTMIRR fix. Namely, it ignored
MFTMIRR and removed the normal check. Windows 10, when it creates
partitions, makes them each with a $MFTMIRR problem. Other Linux
distros trip over this. Win7 CHKDSK can fix it (silently, no status
message during CHKDSK run).

This utility is available on a lot of distros, but is not
part of the default install. You'll need to install it.

http://disktype.sourceforge.net/

Â*Â* sudo disktype /dev/sdX

It might indicate there's some problem.

NTFS might not mount if:

1) Hibernation:

Â*Â* Windows:Â* powercfg /h off

Â*Â* disables both Fast Boot and hibernation to hiberfil.sys

2) NTFS doesn't know how to handle the USN Journal, so it
Â*Â* has the option of invalidating it. Such a thing happens
Â*Â* if you're in write mode and write something. You can erase
Â*Â* the USN Journal while in Windows, although I doubt this would
Â*Â* change anything in a positive way. The Search Indexer will need
Â*Â* to start indexing all over again, on Windows.

3) The NTFS driver may not know what to do with 4Kn disks.
Â*Â* Probably works just fine with 512n and 512e drives.

4) Windows 10 changed cluster size support to 64K. *Don't*
Â*Â* use this feature. It ruins compatibility across Windows systems.
Â*Â* A Windows 7 OS is not going to know what to do when a 2MB cluster
Â*Â* size shows up. Windows 10 uses 4KB clusters for the OS (this became
Â*Â* mandatory part way through the releases). At one time, I had
Â*Â* Windows 10 on a 64KB cluster partition, and it was running fine,
Â*Â* until one day an OS Upgrade came in and said "nuh uh" and I had
Â*Â* to change it. You can make data partitions with 64KB clusters,
Â*Â* and this will work across OSes.

5) Disks can be set up MBR or GPT. I don't know if there are any
Â*Â* issues with partitions on such. I've never seen a problem because
Â*Â* of it. fdisk for mbr, gdisk for gpt.

6) Windows 10 uses Reparse Points, with at least three types of
Â*Â* Reparse Points, if not more. A Junction Point is the oldest custom
Â*Â* NTFS mod. A more recent introduction was a second form of NTFS
Â*Â* compression, uses on WinSXS materials or a few files in System32
Â*Â* seem to be using it, even after the compression has been disabled.
Â*Â* "Normal" NTFS driver response is "I/O error" when an attempt it
Â*Â* made to stat the NTFS files in question. The Linux file manager
Â*Â* will refuse to finish painting the directory contents screen
Â*Â* on the first "I/O error" file it sees.

Lots of these things should not stop mounting in read/write.
They can cause problems when accessing various parts of the disk.

You can start with "powercfg /h off" then go back to Linux
for a look. Next, I'd check whether the packages are set up
properly for what you're doing.

The partition can't be encrypted, because you probably would
not have got as far as you did, if it was. It's not normal
for encryption systems to leave filenames exposed. Options
would be BitLocker (which can use disk drive encryption if it
detects it), TrueCrypt/Veracrypt, or builtin Windows EFS. EFS
might leave the filenames visible. In Windows normally,
compressed and encrypted files are "colored" in File Explorer.
The NTFS new compression might not have a color. Don't know of
any other flavors with colored indicators.

GetFileAttributes function:

FILE_ATTRIBUTE_READONLY = 1 (0x1)
FILE_ATTRIBUTE_HIDDEN = 2 (0x2)
FILE_ATTRIBUTE_SYSTEM = 4 (0x4)
FILE_ATTRIBUTE_DIRECTORY = 16 (0x10)
FILE_ATTRIBUTE_ARCHIVE = 32 (0x20)
FILE_ATTRIBUTE_NORMAL = 128 (0x80)
FILE_ATTRIBUTE_TEMPORARY = 256 (0x100)
FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200)
FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400)Â* Extended attribute used for
"new" compression
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800)Â*Â*Â*Â* Original NTFS compression
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000)

File attributes can be read with

Â*Â* fsutil usn readdata C:\path\to\some\file.ext

*******

You can also use the "second opinion" method. Boot
up a Ubuntu USB key and check whether you can examine
C: from there. You should start with being denied because
of $MFTMIRR damage (chkdsk, Win7, to fix) or the perception
of being hibernated (powercfg /h off, verify C:\hiberfil.sys
is gone). Then Ubuntu should at least allow casual examination
of /media/mount/Win10/users/username/Downloads or similar.
Fiddling with System32 or WinSXS is less certain.

And CHKDSK is a bit of a bear, in that some forms of
damage *do not* leave a message on the screen during
a run. You examine the "fluffy" options you don't normally
use, and switch those on when a partition "seems" to have
a problem, but running a repair doesn't seem to be helping.
Note that Win7 CHKDSK on a Win10 volume really isn't ideal,
but how the hell else are you going to fix MFTMIRR ? It
seems Win7 CHKDSK really wasn't backported for Win10 changes,
and it *does* mess around with stuff that it should not. But
visually, the storage volume still works afterwards. That's
the best that I can manage :-/

In an Administrator Command Prompt while in Windows 10

Â*Â* compact /compactOS:queryÂ*Â*Â*Â*Â*Â*Â*Â*Â* # shows whether "OS wants to
compress"
Â*Â* compact /compactOS:neverÂ*Â*Â*Â*Â*Â*Â*Â*Â* # user tells OS to screw off. This
allows
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # at least some of WinSXS or
System32 files
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # to be accessed. I failed today
to make
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # System32 completely visible this
way!

Â*Â*Â* Paul

Thank you!