On 29/06/2025 1:59 pm, ...winston wrote:

<Snip>

File Explorer' view options has the ability to show both
 - Hidden system files(the option is named 'Hide protected operating
system files). Default setting is hidden(not checked, not shown)
and
 - Show hidden files, folders and drives. Default setting is hidden(not checked, not shown)

Note: Not all folders or folders of files in File Explorer have hidden protected operating system and/or hidden files.
 i.e. depending upon the selected folder and contents, the number of
items shown for folders and files in File Explorer may or may not change.

Reading your reply, ...winston, reminded me of, way back in DOS times
[late 80's/early 90's], Files had four Attributes ...

Read/Write
Archive
System
and 'T' (I think), but I've forgotten what it stood for.

Do they still exist?? Are there more??

(WOW!! Trip down (mental not silicon) memory lane!! ;-) )
--
Daniel70

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/06/2025 12:17 am, Daniel70 wrote:

On 29/06/2025 1:59 pm, ...winston wrote:

<Snip>

File Explorer' view options has the ability to show both
  - Hidden system files(the option is named 'Hide protected operating
system files). Default setting is hidden(not checked, not shown)
and
  - Show hidden files, folders and drives. Default setting is
hidden(not checked, not shown)

Note: Not all folders or folders of files in File Explorer have hidden
protected operating system and/or hidden files.
  i.e. depending upon the selected folder and contents, the number of
items shown for folders and files in File Explorer may or may not change.

Reading your reply, ...winston, reminded me of, way back in DOS times
[late 80's/early 90's], Files had four Attributes ...

Read/Write
Archive
System
and 'T' (I think), but I've forgotten what it stood for.

Just came to me ... The last wasn't 'T' but 'H' for Hidden!!

Do they still exist?? Are there more??

(WOW!! Trip down (mental not silicon) memory lane!! ;-) )

--
Daniel70

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/29/25 12:23 PM, J. P. Gilliver wrote:

On 2025/6/29 15:20:1, Daniel70 wrote:

On 30/06/2025 12:17 am, Daniel70 wrote:

[]

Reading your reply, ...winston, reminded me of, way back in DOS times [late 80's/early
90's], Files had four Attributes ...

Read/Write
Archive
System
and 'T' (I think), but I've forgotten what it stood for.

Just came to me ... The last wasn't 'T' but 'H' for Hidden!!

You beat me to it (-:>>

Do they still exist?? Are there more??

(WOW!! Trip down (mental not silicon) memory lane!! ;-) )

They certainly still exist (in this W10, anyway): if you right-click on a column header in
File Explorer, and look through the list of possible headings, Attributes is one of the
options. I just tried turning it on for an obscure folder, and it looks as if A - archive
- is still turned on by default for new files, the others not. (IIRR, some old DOS
functionality toggled A _on the original_ when a file was copied, as part of some way of
saving you from having to copy again a file that had not changed - hence it standing for
"archive" [meaning "this file hasn't been archived"].)
R (which I think of as "read-only" rather than "Read/Write", but that's really just
semantics) is still used by some softwares; it usually only shows its head when you try to
save something you've been working on, and the software says it can't, and brings up the
save window for you to type in a different filename. I'm pretty certain that any file on
(or copied from) a CD or DVD will have the R bit set, which seems fair enough.

I _think_ S was used when you were making a boot floppy (!) - was the command "sys a:"? -
and resulted in files with that attribute being included.

I don't know if there are any more - I think not, as I think they used a four-bit space
somewhere (in the filename or directory maybe?). Obviously lots of file information _is_
now added, but a lot of it is in metadata in the file itself (I use WinAmp to edit it for
MP3 files, VLC for video files [doesn't work for all types], and IrfanView for image
files; plenty of other utilities can edit them too, including File Manager itself for some
of them). I think there's also some information in the sort of "shadow" copy of the
directory information that NTFS uses ("journalling" is it?); I've never learnt that
properly - Paul knows. (As with everything!)

If you open a CMD prompt and type "attrib /?" you'll see:

ATTRIB - Displays or changes file attributes.

Syntax:
ATTRIB [+R | -R] [+A | -A ] [+S | -S] [+H | -H] [drive:][path][filename]
[/S [/D]]

Where:

+ Sets an attribute.
- Clears an attribute.
R Read-only file attribute.
A Archive file attribute.
S System file attribute.
H Hidden file attribute.
[drive:][path][filename]
Specifies a file or files for attrib to process.
/S Processes matching files in the current folder and all subfolders.
/D Processes folders as well.

The RASH are the 3 file settings you can toggle with attrib, "attrib +a file"

--
Linux Mint 22.1, Thunderbird 128.11.1esr, Mozilla Firefox 140.0.1
Alan K.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMjAyNS82LzI5IDE3OjMzOjMwLCBBbGFuIEsuIHdyb3RlOg0KW10NCg0KPiBUaGUgUkFT SCBhcmUgdGhlIDMgZmlsZSBzZXR0aW5ncyB5b3UgY2FuIHRvZ2dsZSB3aXRoIGF0dHJpYizC oCAiYXR0cmliICthIA0KPiBmaWxlIg0KPiANCjQgKC06DQoNCi0tIA0KSi4gUC4gR2lsbGl2 ZXIuIFVNUkE6IDE5NjAvPDE5ODUgTUIrK0coKUFMLUlTLUNoKysocClBckBUK0grU2gwITpg KUROQWYNCgANCkZyZWVkb20gb2YgdGhlIHByZXNzIGlzIGxpbWl0ZWQgdG8gdGhvc2Ugd2hv IGhhdmUgb25lLg0K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMjAyNS82LzI5IDE1OjIwOjEsIERhbmllbDcwIHdyb3RlOg0KPiBPbiAzMC8wNi8yMDI1 IDEyOjE3IGFtLCBEYW5pZWw3MCB3cm90ZToNCltdDQoNCj4+IFJlYWRpbmcgeW91ciByZXBs eSwgLi4ud2luc3RvbiwgcmVtaW5kZWQgbWUgb2YsIHdheSBiYWNrIGluIERPUyB0aW1lcyAN Cj4+IFtsYXRlIDgwJ3MvZWFybHkgOTAnc10sIEZpbGVzIGhhZCBmb3VyIEF0dHJpYnV0ZXMg Li4uDQo+Pg0KPj4gUmVhZC9Xcml0ZQ0KPj4gQXJjaGl2ZQ0KPj4gU3lzdGVtDQo+PiBhbmQg J1QnIChJIHRoaW5rKSwgYnV0IEkndmUgZm9yZ290dGVuIHdoYXQgaXQgc3Rvb2QgZm9yLg0K PiANCj4gSnVzdCBjYW1lIHRvIG1lIC4uLiBUaGUgbGFzdCB3YXNuJ3QgJ1QnIGJ1dCAnSCcg Zm9yIEhpZGRlbiEhDQoNCllvdSBiZWF0IG1lIHRvIGl0ICgtOj4+DQo+PiBEbyB0aGV5IHN0 aWxsIGV4aXN0Pz8gQXJlIHRoZXJlIG1vcmU/Pw0KPj4NCj4+IChXT1chISBUcmlwIGRvd24g KG1lbnRhbCBub3Qgc2lsaWNvbikgbWVtb3J5IGxhbmUhISA7LSkgKQ0KVGhleSBjZXJ0YWlu bHkgc3RpbGwgZXhpc3QgKGluIHRoaXMgVzEwLCBhbnl3YXkpOiBpZiB5b3UgcmlnaHQtY2xp Y2sgb24gDQphIGNvbHVtbiBoZWFkZXIgaW4gRmlsZSBFeHBsb3JlciwgYW5kIGxvb2sgdGhy b3VnaCB0aGUgbGlzdCBvZiBwb3NzaWJsZSANCmhlYWRpbmdzLCBBdHRyaWJ1dGVzIGlzIG9u ZSBvZiB0aGUgb3B0aW9ucy4gSSBqdXN0IHRyaWVkIHR1cm5pbmcgaXQgb24gDQpmb3IgYW4g b2JzY3VyZSBmb2xkZXIsIGFuZCBpdCBsb29rcyBhcyBpZiBBIC0gYXJjaGl2ZSAtIGlzIHN0 aWxsIHR1cm5lZCANCm9uIGJ5IGRlZmF1bHQgZm9yIG5ldyBmaWxlcywgdGhlIG90aGVycyBu b3QuIChJSVJSLCBzb21lIG9sZCBET1MgDQpmdW5jdGlvbmFsaXR5IHRvZ2dsZWQgQSBfb24g dGhlIG9yaWdpbmFsXyB3aGVuIGEgZmlsZSB3YXMgY29waWVkLCBhcyANCnBhcnQgb2Ygc29t ZSB3YXkgb2Ygc2F2aW5nIHlvdSBmcm9tIGhhdmluZyB0byBjb3B5IGFnYWluIGEgZmlsZSB0 aGF0IGhhZCANCm5vdCBjaGFuZ2VkIC0gaGVuY2UgaXQgc3RhbmRpbmcgZm9yICJhcmNoaXZl IiBbbWVhbmluZyAidGhpcyBmaWxlIGhhc24ndCANCmJlZW4gYXJjaGl2ZWQiXS4pDQpSICh3 aGljaCBJIHRoaW5rIG9mIGFzICJyZWFkLW9ubHkiIHJhdGhlciB0aGFuICJSZWFkL1dyaXRl IiwgYnV0IHRoYXQncyANCnJlYWxseSBqdXN0IHNlbWFudGljcykgaXMgc3RpbGwgdXNlZCBi eSBzb21lIHNvZnR3YXJlczsgaXQgdXN1YWxseSBvbmx5IA0Kc2hvd3MgaXRzIGhlYWQgd2hl biB5b3UgdHJ5IHRvIHNhdmUgc29tZXRoaW5nIHlvdSd2ZSBiZWVuIHdvcmtpbmcgb24sIA0K YW5kIHRoZSBzb2Z0d2FyZSBzYXlzIGl0IGNhbid0LCBhbmQgYnJpbmdzIHVwIHRoZSBzYXZl IHdpbmRvdyBmb3IgeW91IHRvIA0KdHlwZSBpbiBhIGRpZmZlcmVudCBmaWxlbmFtZS4gSSdt IHByZXR0eSBjZXJ0YWluIHRoYXQgYW55IGZpbGUgb24gKG9yIA0KY29waWVkIGZyb20pIGEg Q0Qgb3IgRFZEIHdpbGwgaGF2ZSB0aGUgUiBiaXQgc2V0LCB3aGljaCBzZWVtcyBmYWlyIGVu b3VnaC4NCg0KSSBfdGhpbmtfIFMgd2FzIHVzZWQgd2hlbiB5b3Ugd2VyZSBtYWtpbmcgYSBi b290IGZsb3BweSAoISkgLSB3YXMgdGhlIA0KY29tbWFuZCAic3lzIGE6Ij8gLSBhbmQgcmVz dWx0ZWQgaW4gZmlsZXMgd2l0aCB0aGF0IGF0dHJpYnV0ZSBiZWluZyANCmluY2x1ZGVkLg0K DQpJIGRvbid0IGtub3cgaWYgdGhlcmUgYXJlIGFueSBtb3JlIC0gSSB0aGluayBub3QsIGFz IEkgdGhpbmsgdGhleSB1c2VkIGEgDQpmb3VyLWJpdCBzcGFjZSBzb21ld2hlcmUgKGluIHRo ZSBmaWxlbmFtZSBvciBkaXJlY3RvcnkgbWF5YmU/KS4gDQpPYnZpb3VzbHkgbG90cyBvZiBm aWxlIGluZm9ybWF0aW9uIF9pc18gbm93IGFkZGVkLCBidXQgYSBsb3Qgb2YgaXQgaXMgaW4g DQptZXRhZGF0YSBpbiB0aGUgZmlsZSBpdHNlbGYgKEkgdXNlIFdpbkFtcCB0byBlZGl0IGl0 IGZvciBNUDMgZmlsZXMsIFZMQyANCmZvciB2aWRlbyBmaWxlcyBbZG9lc24ndCB3b3JrIGZv ciBhbGwgdHlwZXNdLCBhbmQgSXJmYW5WaWV3IGZvciBpbWFnZSANCmZpbGVzOyBwbGVudHkg b2Ygb3RoZXIgdXRpbGl0aWVzIGNhbiBlZGl0IHRoZW0gdG9vLCBpbmNsdWRpbmcgRmlsZSAN Ck1hbmFnZXIgaXRzZWxmIGZvciBzb21lIG9mIHRoZW0pLiBJIHRoaW5rIHRoZXJlJ3MgYWxz byBzb21lIGluZm9ybWF0aW9uIA0KaW4gdGhlIHNvcnQgb2YgInNoYWRvdyIgY29weSBvZiB0 aGUgZGlyZWN0b3J5IGluZm9ybWF0aW9uIHRoYXQgTlRGUyB1c2VzIA0KKCJqb3VybmFsbGlu ZyIgaXMgaXQ/KTsgSSd2ZSBuZXZlciBsZWFybnQgdGhhdCBwcm9wZXJseSAtIFBhdWwga25v d3MuIA0KKEFzIHdpdGggZXZlcnl0aGluZyEpDQotLSANCkouIFAuIEdpbGxpdmVyLiBVTVJB OiAxOTYwLzwxOTg1IE1CKytHKClBTC1JUy1DaCsrKHApQXJAVCtIK1NoMCE6YClETkFmDQoA DQpUaGUgJ2dvb2QgbGlmZScgYmVnaW5zIHdoZW4geW91IHN0b3Agd2FudGluZyBhIGJldHRl ciBvbmUNCihOa29zaXBoYW1iaWxpIEUuIE1vbGFwaXMpDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-29 18:23, J. P. Gilliver wrote:

On 2025/6/29 15:20:1, Daniel70 wrote:

On 30/06/2025 12:17 am, Daniel70 wrote:

[]

Reading your reply, ...winston, reminded me of, way back in DOS times
[late 80's/early 90's], Files had four Attributes ...

Read/Write
Archive
System
and 'T' (I think), but I've forgotten what it stood for.

Just came to me ... The last wasn't 'T' but 'H' for Hidden!!

You beat me to it (-:>>

Do they still exist?? Are there more??

(WOW!! Trip down (mental not silicon) memory lane!! ;-) )

They certainly still exist (in this W10, anyway): if you right-click on
a column header in File Explorer, and look through the list of possible headings, Attributes is one of the options. I just tried turning it on
for an obscure folder, and it looks as if A - archive - is still turned
on by default for new files, the others not. (IIRR, some old DOS functionality toggled A _on the original_ when a file was copied, as
part of some way of saving you from having to copy again a file that had
not changed - hence it standing for "archive" [meaning "this file hasn't
been archived"].)

The A+ attribute was cleared only by backup software. At least that was
the intention. Modify a file, and it would be automatically set. An
incremental backup would only store those files with A+ and clear it.

R (which I think of as "read-only" rather than "Read/Write", but that's really just semantics) is still used by some softwares; it usually only
shows its head when you try to save something you've been working on,
and the software says it can't, and brings up the save window for you to
type in a different filename. I'm pretty certain that any file on (or
copied from) a CD or DVD will have the R bit set, which seems fair enough.

I _think_ S was used when you were making a boot floppy (!) - was the
command "sys a:"? - and resulted in files with that attribute being
included.

S+ meant that the file could not be moved (it would stop working). That
was because the boot code had hardcoded the location of the system files.

I don't know if there are any more - I think not, as I think they used a four-bit space somewhere (in the filename or directory maybe?).
Obviously lots of file information _is_ now added, but a lot of it is in metadata in the file itself (I use WinAmp to edit it for MP3 files, VLC
for video files [doesn't work for all types], and IrfanView for image
files; plenty of other utilities can edit them too, including File
Manager itself for some of them). I think there's also some information
in the sort of "shadow" copy of the directory information that NTFS uses ("journalling" is it?); I've never learnt that properly - Paul knows.
(As with everything!)

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Jun 2025 00:17:49 +1000, Daniel70 wrote:

[snip]

Reading your reply, ...winston, reminded me of, way back in DOS times
[late 80's/early 90's], Files had four Attributes ...

Read/Write Archive System and 'T' (I think), but I've forgotten what it
stood for.

You probably mean the Hidden attribute.

Do they still exist?? Are there more??

IIRC, 2 other bits (in this byte in the directory entry) were used. One indicates the entry is for a subdirectory rather than for a file. The
other indicates the directory entry (root directory only) is for the disk volume label.

I don't know of any use for bits 6 & 7.

(WOW!! Trip down (mental not silicon) memory lane!! ;-) )

--
Mark Lloyd
http://notstupid.us/

"The fool says in his heart, 'There is no God.' The Wise Man Says it to
the World.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 6/29/2025 12:47 PM, J. P. Gilliver wrote:

On 2025/6/29 17:33:30, Alan K. wrote:
[]

The RASH are the 3 file settings you can toggle with attrib,  "attrib +a file"

4 (-:

There are more attributes than this.

The ones discussed to this point, are the Legacy ones that Bill Gates uses :

on NTFS:

fsutil usn readdata Y:\Windows\Logs\CBS\CBS.log

Constants - the following attribute values are returned by the 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)
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) <--- Old Compression, New Compression is a Reparse Point and not an attribute
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000) <--- EFS ("old" encryption)

If "fsutil.exe" returns 0x803, that is "COMPRESSED + HIDDEN + READONLY".
They are bitfields.

Old compression or single-file-EFS-encrypted files, show in
File Explorer with a blue-colored link, and the feature
is only supported on 4K cluster NTFS file systems. (Modern Windows only
allows 4K cluster C: drives, and no longer tolerates 64KB clusters on
C: , as I discovered one day.)

Bitlocker or FDE encrypted disk drives, are another level of encryption separate from the application of EFS.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025/6/30 0:14:52, Paul wrote:
[]

The ones discussed to this point, are the Legacy ones that Bill Gates uses :

on NTFS:

fsutil usn readdata Y:\Windows\Logs\CBS\CBS.log

Constants - the following attribute values are returned by the 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)
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) <--- Old Compression, New Compression is a Reparse Point and not an attribute
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000) <--- EFS ("old" encryption)

If "fsutil.exe" returns 0x803, that is "COMPRESSED + HIDDEN + READONLY".
They are bitfields.

Interesting
(a) that the old RASH use the bottom three bits, but but one from a
higher nybble
(b) that 8 (0x8) isn't used at all. [Nor are 64 (0x40) and 32768 (0x8000).]

Obviously this takes four bytes per file. In systems before NTFS, did it
only take one, or half? Where - in the directory alongside the filename (something like the drwxrwxrwx of UNIX [and I presume Linux])?>

Old compression or single-file-EFS-encrypted files, show in
File Explorer with a blue-colored link, and the feature

Ah, so _that_'s what the blue means. (And I never thought of File
Explorer's lines as links, but obviously they are!)

is only supported on 4K cluster NTFS file systems. (Modern Windows only allows 4K cluster C: drives, and no longer tolerates 64KB clusters on
C: , as I discovered one day.)

(Do such files take less space on disk, and are automatically
uncompressed when accessed?)>

Bitlocker or FDE encrypted disk drives, are another level of encryption separate from the application of EFS.

Paul

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"He who will not reason is a bigot;
he who cannot is a fool;
he who dares not is a slave."
- Sir William Drummond

Above all things, use your mind.
Don't be that bigot, fool, or slave.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 6/30/2025 2:22 AM, J. P. Gilliver wrote:

On 2025/6/30 0:14:52, Paul wrote:
[]

The ones discussed to this point, are the Legacy ones that Bill Gates uses : >>
on NTFS:

     fsutil usn readdata Y:\Windows\Logs\CBS\CBS.log

Constants - the following attribute values are returned by the 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)
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800)         <--- Old Compression, New Compression is a Reparse Point and not an attribute
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000)          <--- EFS ("old" encryption)

If "fsutil.exe" returns 0x803, that is "COMPRESSED + HIDDEN + READONLY".
They are bitfields.

Interesting
(a) that the old RASH use the bottom three bits, but but one from a higher nybble
(b) that 8 (0x8) isn't used at all. [Nor are 64 (0x40) and 32768 (0x8000).]

Obviously this takes four bytes per file. In systems before NTFS, did it only take one, or half? Where - in the directory alongside the filename (something like the drwxrwxrwx of UNIX [and I presume Linux])?>

Old compression or single-file-EFS-encrypted files, show in
File Explorer with a blue-colored link, and the feature

Ah, so _that_'s what the blue means. (And I never thought of File Explorer's lines as links, but obviously they are!)

is only supported on 4K cluster NTFS file systems. (Modern Windows only
allows 4K cluster C: drives, and no longer tolerates 64KB clusters on
C: , as I discovered one day.)

(Do such files take less space on disk, and are automatically uncompressed when accessed?)>

Bitlocker or FDE encrypted disk drives, are another level of encryption
separate from the application of EFS.

    Paul

The decompression scheme of "old compression" is automatic as you would expect. Without going into detail, the old compression scheme causes indigestion on NTFS,
so if using such a feature for an entire partition, you can have issues. The end result is, that most of the time, it is not even worth considering old compression
as a solution to any problem. It's just not worth it.

The "New Compression" exists mainly to annoy Linux access to NTFS. Like if you wanted
to quietly remove some files with pestilent permissions, using Linux, if something
has had New Compression applied to it, Linux can show "I/O Error", which is an inappropriate error mapping. It isn't a hard drive problem, it's just the parser
does not understand new compression. There was a recent change to the error message,
but it still isn't going to work.

Linux has two NTFS drivers. There is a kernel (Ring0) driver and there
is a FUSE (Ring3 user-land driver), and one of those is more likely
to know what New Compression is, compared to the old. But because the
newer driver was added, without a good test plan, one of the drivers
may have some rough edges. Not wanting to go into details, I would just
point out that two methods exist for access, and if you found yourself
having trouble with NTFS, you can switch them.

A Windows user may not be called upon to suss out the difference between
these, while using Linux for maintenance. But this is just to show how
easy it is to set up a basic mount (normally the automounter does this
for you and the automounter has some preference for one over the other).

https://phoenixnap.com/kb/mount-ntfs-linux

sudo apt install fuse # These steps may already have been done for you sudo apt install ntfs-3g # They are included for "technical completeness" when you get stuck.

sudo mount -t ntfs-3g /dev/sdb2 /mnt/ntfs2/ # older FUSE driver

sudo mount -t ntfs /dev/sdb1 /mnt/ntfs1 # newer kernel driver ?

Windows likes to use New Compression (unnecessarily) in Windows areas.
Not every file might be compressed. The fun happens when you want to
delete something from System32. I can hear <snickering> all the way
from Redmond.

*******

The compression control in Windows, is like this. This is my
annoyed Linux user note on the topic :-)

fsutil behavior query disablecompression
fsutil behavior set disablecompression 1 # disable new compression, compressed items NOT removed
fsutil behavior set disablecompression 0

gpedit.msc # Windows Pro
computer configuration\Administrative template\system\filesystem\ntfs\Do not allow compression

Compression utility handling was designed by idiots. You cannot
change the compression state, without making a brand new file, losing
all the permissions and MIC-ENUM and so on. Switching compression on and off, does not remove it from the files.

In case you were thinking "I'm just going to do that, use disablecompression, as a good default for my Win10"...

You can, but if you receive a Safe OS update during a Patch Tuesday,
disabling compression prevents successful patch completion. There was
NO NEED AT ALL for them to conflate these two issues. The DISM thing
that makes the WIM, does not give a flying fuck about New Compression.
The compressor for a WIM is a solid block compressor for making
smaller WIMs, like a .tar.gz in a sense. The WinRE.wim file in the
hidden 600MB partition, the solid block archive can have various
compressors applied to it (XPRESS?). It can even have NO COMPRESSION AT ALL,
if for example... you could not compress for some reason.

So anyway, they just make it fail, if they detect you've used my
little setting above.

As a consequence, I'm sometimes fiddling with that setting,
then putting it back, and so on. And all in the name of a better
experience when fixing stuff from Linux.

I don't know if I have successfully transferred my sense of
frustration with the way they design stuff, but I am
royally fucking pissed.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-30 01:14, Paul wrote:

On Sun, 6/29/2025 12:47 PM, J. P. Gilliver wrote:

On 2025/6/29 17:33:30, Alan K. wrote:
[]

The RASH are the 3 file settings you can toggle with attrib,  "attrib +a file"

4 (-:

There are more attributes than this.

The ones discussed to this point, are the Legacy ones that Bill Gates uses :

on NTFS:

fsutil usn readdata Y:\Windows\Logs\CBS\CBS.log

Constants - the following attribute values are returned by the 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)
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) <--- Old Compression, New Compression is a Reparse Point and not an attribute
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000) <--- EFS ("old" encryption)

Interesting, thanks. So the 4 traditional do not map to the first 4 bits.


--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-30 10:07, Paul wrote:

I don't know if I have successfully transferred my sense of
frustration with the way they design stuff, but I am
royally fucking pissed.

Indeed! Thanks for the summary, appreciated.

So, when I create backup images from windows, I will keep using
dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No,
something else :-?

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025/7/4 9:38:37, Carlos E.R. wrote:
[]

So, when I create backup images from windows, I will keep using dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No,
something else :-?

When I create a backup image, I boot from a bootable Macrium DVD I made
- it isn't "fancy". (I think the other similar - Acronis, EAseus, etc. -
are similar.) [For Windows 7 and earlier, Macrium 5 or 6 - either will
do - will actually fit on a mini-CD, but won't work with recent Windows
10.] Macrium lets one choose (from a very simple 3-option dropdown) the
level of compression - none, moderate, or more - defaulting to the
middle one.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

One of my tricks as an armchair futurist is to "predict" things that
are already happening and watch people tell me it will never happen.
Scott Adams, 2015-3-9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 7/4/2025 8:40 PM, J. P. Gilliver wrote:

On 2025/7/4 9:38:37, Carlos E.R. wrote:
[]

So, when I create backup images from windows, I will keep using dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No, something else :-?

When I create a backup image, I boot from a bootable Macrium DVD I made - it isn't "fancy". (I think the other similar - Acronis, EAseus, etc. - are similar.) [For Windows 7 and earlier, Macrium 5 or 6 - either will do - will actually fit on a mini-CD,

but won't work with recent Windows 10.] Macrium lets one choose (from a very simple 3-option dropdown) the level of compression - none, moderate, or more - defaulting to the middle one.

The Macrium compressor is not much of a compressor.

That's because it can't afford to burden the user
with a slow backup. I don't know if it is stated somewhere,
exactly what compressor it uses.

And Macrium won't "use all your cores" either. It's
not that kind of program.

The Windows 7 Backup, is potentially "the fastest backup going".
But when you go to restore, does it always work ? Dunno.
I don't think the Windows 7 Backup program uses checksums,
and there is no "Verify" for the VHD/VHDX containers it collects.
I've never spotted any metadata that suggests otherwise.

*******

"dd" as a backup works, but you have to be patient.

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take
five hours. That's the definition of patient.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025/7/5 7:49:45, Paul wrote:
[]

The Macrium compressor is not much of a compressor.

That's because it can't afford to burden the user
with a slow backup. I don't know if it is stated somewhere,
exactly what compressor it uses.

Since I only tended to backup what's needed to restore a working system
(C: plus any hidden partitions Macrium finds [I keep all my data -
including downloaded installers - on D:, so C: is just OS plus
_installed_ software), I tended to select no compression (on the basis
one less thing to go wrong), or if not enough space on the backup drive,
the medium compression.>

And Macrium won't "use all your cores" either. It's
not that kind of program.

The Windows 7 Backup, is potentially "the fastest backup going".
But when you go to restore, does it always work ? Dunno.
I don't think the Windows 7 Backup program uses checksums,
and there is no "Verify" for the VHD/VHDX containers it collects.
I've never spotted any metadata that suggests otherwise.

Since I was never quite sure what the inbuilt backup backed up - e. g.,
how much work I'd need after a restore to get things back how I wanted
them - I never used it. (I might have once, just to _have_ that sort of
backup, but never used what it made.)>

*******

"dd" as a backup works, but you have to be patient.

That's always looked too complicated for simple me (despite help from
those like yourself who try to explain it to us). Macrium Free _seems_
not too bad - though of course I know it's to some extent a matter of familiarity.>

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take

Wow! I think my last (remember, only a small C: and some tiny
partitions), was about a quarter of an hour; I presume yours was to an (internal?) SSD of some sort. (Mine was to an external spinner, albeit
via USB3.)

five hours. That's the definition of patient.

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD
took an unconscionable time to _boot_ (half an hour maybe? - With long
pauses when it didn't seem to be doing anything), though once it _had_
booted, the actual restore was fine and not too long.>

Paul

John (G.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

When I'm good, I'm very good. But when I'm bad - I'm better! (Mae West)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 7/5/2025 11:52 AM, J. P. Gilliver wrote:

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD took an unconscionable time to _boot_ (half an hour maybe? - With long pauses when it didn't seem to be doing anything), though once it _had_ booted, the actual restore was fine and

not too long.>

    Paul

John (G.)

The Macrium ReScue OS, is stored as a .wim file, and it is
loaded as a RAMDisk. when booted, the OS partition is called
X: which leaves the letter C: available if it were needed to
some purpose. It should be a "straight read of 300MB of material",
followed by the usual Microsoft code load behavior.

If you aren't doing anything with the media of importance,
you might notice that ejecting the Macrium OS media, affects
the session not-at-all. That's because the OS is now in the\
RAMDisk X: set up on your machine and references to the boot
.wim are no longer needed..

To restore an MRIMG, I suspect the program starts by examining
some indexes it stored at the end of the session. It has to load
some of that info, before the restore-proper can begin. This is
important if you are restoring and changing the size of the partition
as you restore (making it smaller).

If the MRIMG data being restored is on optical media, that's a
pretty slow source. Once the restore gets going, the reads should
be sequential.

IDK, I don't know if I'm patient enough, to allow a thing like that
to proceed without some optimizing.

I did once test a Windows 7 Backup to DVD media, and the Microsoft
burn utility did not have code for erasing re-writable media. I was
flipping out the DVD, and erasing it with ImgBurn, then popping it
back in so the Microsoft backup code could do its thing. I think it
took me two hours and four pieces of media, and I was fit to be
tied by the time I was finished.

Today, I would think you would need a title similar to
Mother Theresa for attempting such a stunt :-) So so slow.
I could row a boat faster than this.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025/7/6 7:41:52, Paul wrote:

On Sat, 7/5/2025 11:52 AM, J. P. Gilliver wrote:

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD took an unconscionable time to _boot_ (half an hour maybe? - With long pauses when it didn't seem to be doing anything), though once it _had_ booted, the actual restore was fine and

not too long.>

    Paul

John (G.)

The Macrium ReScue OS, is stored as a .wim file, and it is
loaded as a RAMDisk. when booted, the OS partition is called
X: which leaves the letter C: available if it were needed to
some purpose. It should be a "straight read of 300MB of material",
followed by the usual Microsoft code load behavior.

Interesting.>

If you aren't doing anything with the media of importance,
you might notice that ejecting the Macrium OS media, affects
the session not-at-all. That's because the OS is now in the\
RAMDisk X: set up on your machine and references to the boot
.wim are no longer needed..

Useful to know.>

To restore an MRIMG, I suspect the program starts by examining
some indexes it stored at the end of the session. It has to load
some of that info, before the restore-proper can begin. This is
important if you are restoring and changing the size of the partition
as you restore (making it smaller).

If the MRIMG data being restored is on optical media, that's a
pretty slow source. Once the restore gets going, the reads should
be sequential.

No, it was on an external HDD (USB2) [Macrium booting from DVD]. But I'm
pretty sure the unconscionable wait was _before_ the restore started
(before it asked us to select which restore file, or something like
that). Before the Macrium screens appeared. IIRR - it was some years
ago. _Might_ have been when the system in question had a slow internal
HDD.>

IDK, I don't know if I'm patient enough, to allow a thing like that
to proceed without some optimizing.

I doubt I could optimise Macrium.>

I did once test a Windows 7 Backup to DVD media, and the Microsoft
burn utility did not have code for erasing re-writable media. I was
flipping out the DVD, and erasing it with ImgBurn, then popping it
back in so the Microsoft backup code could do its thing. I think it
took me two hours and four pieces of media, and I was fit to be
tied by the time I was finished.

I can see that! I've not yet played with rewritable DVD; I remember
rewritable CDs being something of a pain reliability-wise. (I used to
use them in the giant-floppy mode - often proprietary with the drive
drivers in those days! - for transferring between machines [e. g. work
and home].)>

Today, I would think you would need a title similar to
Mother Theresa for attempting such a stunt :-) So so slow.
I could row a boat faster than this.

Paul

(-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Sarcasm: Barbed ire

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-05 08:49, Paul wrote:

On Fri, 7/4/2025 8:40 PM, J. P. Gilliver wrote:

On 2025/7/4 9:38:37, Carlos E.R. wrote:
[]

So, when I create backup images from windows, I will keep using dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No, something else :-?

When I create a backup image, I boot from a bootable Macrium DVD I made - it isn't "fancy". (I think the other similar - Acronis, EAseus, etc. - are similar.) [For Windows 7 and earlier, Macrium 5 or 6 - either will do - will actually fit on a mini-CD,

but won't work with recent Windows 10.] Macrium lets one choose (from a very simple 3-option dropdown) the level of compression - none, moderate, or more - defaulting to the middle one.

The Macrium compressor is not much of a compressor.

That's because it can't afford to burden the user
with a slow backup. I don't know if it is stated somewhere,
exactly what compressor it uses.

And Macrium won't "use all your cores" either. It's
not that kind of program.

The Windows 7 Backup, is potentially "the fastest backup going".
But when you go to restore, does it always work ? Dunno.
I don't think the Windows 7 Backup program uses checksums,
and there is no "Verify" for the VHD/VHDX containers it collects.
I've never spotted any metadata that suggests otherwise.

*******

"dd" as a backup works, but you have to be patient.

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take
five hours. That's the definition of patient.

Sure. But it is safe. Even if some daft software stored data in empty
sectors. There are some.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 7/10/2025 6:37 AM, Carlos E.R. wrote:

On 2025-07-05 08:49, Paul wrote:

"dd" as a backup works, but you have to be patient.

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take
five hours. That's the definition of patient.

Sure. But it is safe. Even if some daft software stored data in empty sectors. There are some.

A contemporary in another group, would likely agree with you,
as he managed to trash his setup, by being in a rush.
(He actually tried to use the Windows 7 Backup, among other things.)

If he'd had a "dd" backup, he would likely be OK now :-)

That's the thing about backups, "you only want one when you
don't have one" :-)

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)