• More Mac related but...

    From philo@21:1/5 to All on Sun Dec 12 14:35:02 2021
    Asking here because no one on the Mac groups seems to have a clue about anything other than hurling insults.


    I recently had to work on a Mac, where the owner had forgotten the
    password. It was one that had a firmware password so I could not use any
    of the normal recovery options.

    I figured all I'd have to do is put the drive in my Linux machine and
    delete /var/db/.AppleSetupDone

    (that will allow the setup of a new administrator account.)


    I was able to view the file but due to the drive being journaled, unable
    to delete it.


    I figured that as long as I had the drive in my machine, I might as well
    backup their data but I was also unable to to that unless I did so as root.

    I had to copy the data to a root-owned folder but after I did, and even
    after I changed ownership to my user profile, was unable to copy the
    data to my own profile.


    My question is...what is it about HFS+ , journaled that Linux cannot handle...and why?


    I ended up connecting the drive to my old iMac.
    Finally, in order for me to delete .AppleSetupDone, I had to do so from
    the terminal. The file did not appear in the GUI file manager, even
    after I hit the keys to "show hidden."

    Does HFS+ have both hidden and system files in the way DOS and Windows do?

    Is the dot in from of the file name and indication of "system?"


    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to philo on Sun Dec 12 18:23:04 2021
    On 12/12/2021 3:35 PM, philo wrote:

    Asking here because no one on the Mac groups seems to have a clue about anything other than hurling insults.


    I recently had to work on a Mac, where the owner had forgotten the password. It was one that had a firmware password so I could not use any of the normal recovery options.

    I figured all I'd have to do is put the drive in my Linux machine and delete /var/db/.AppleSetupDone

    (that will allow the setup of a new administrator account.)


    I was able to view the file but due to the drive being journaled, unable to delete it.


    I figured that as long as I had the drive in my machine, I might as well backup their data but I was also unable to to that unless I did so as root.

    I had to copy the data to a root-owned folder but after I did, and even after I changed ownership to my user profile, was unable to copy the data to my own profile.


    My question is...what is it about HFS+ , journaled that Linux cannot handle...and why?


    I ended up connecting the drive to my old iMac.
    Finally, in order for me to delete .AppleSetupDone, I had to do so from the terminal. The file did not appear in the GUI file manager, even after I hit the keys to "show hidden."

    Does HFS+ have both hidden and system files in the way DOS and Windows do?

    Is the dot in from of the file name and indication of "system?"


    Thanks.


    To do a backup, I did a "dd" on a Mac G4, to keep an archival quality image. That way, if I screwed up some "more clever" backup method at the time, I'd never have to
    go back into the thing.

    Here's a reference to some background info. I doubt it will directly
    answer your questions about manipulations there. You will recognize some familiar concepts when you skim through this.

    https://developer.apple.com/library/archive/technotes/tn/tn1150.html

    Sage advice on messing with journals. Generally, there's a habit amongst foreign file system developers to not support journaling. Which is naughty.
    It endangers data integrity (like if the file system was uncleanly shut
    down, and you were hoping the journal would be available on the next boot
    cycle to support proper cleanup). Naturally, this is the antithesis of maintenance people - and their need to write to a volume using a foreign method.

    https://help.ubuntu.com/community/hfsplus

    Be careful with Gparted. I tried to manipulate partitions with
    GParted, and it trashed the drive. But with my backup, I didn't
    particularly care. As, after all, this is how you "dial in" disk
    tools. You test them carefully, for precisely this reason.
    The first time you use a tool, have that "dd" backup salted away
    for safe keeping.

    In Linux, you can use the "disktype" utility on the some.img file
    created by "dd", and it will tell you about the partition structure.
    Using the offset info, you could also attempt a loopback mount
    with offset, and then you would have access to the partition.
    But only if the journal has been handled (somehow) safely.

    --- mac__sda2.img
    Regular file, size 74.53 GiB (80026877952 bytes)
    Apple partition map, 10 entries
    Partition 1: 31.50 KiB (32256 bytes, 63 sectors from 1)
    Type "Apple_partition_map"
    Partition 2: 28 KiB (28672 bytes, 56 sectors from 64)
    Type "Apple_Driver43"
    Partition 3: 28 KiB (28672 bytes, 56 sectors from 120)
    Type "Apple_Driver43"
    Partition 4: 28 KiB (28672 bytes, 56 sectors from 176)
    Type "Apple_Driver_ATA"
    Partition 5: 28 KiB (28672 bytes, 56 sectors from 232)
    Type "Apple_Driver_ATA"
    Partition 6: 256 KiB (262144 bytes, 512 sectors from 288)
    Type "Apple_FWDriver"
    Blank disk/medium
    Partition 7: 256 KiB (262144 bytes, 512 sectors from 800)
    Type "Apple_Driver_IOKit"
    Blank disk/medium
    Partition 8: 256 KiB (262144 bytes, 512 sectors from 1312)
    Type "Apple_Patches"
    Partition 9: 74.53 GiB (80025423872 bytes, 156299656 sectors from 1824) <=== fun starts here
    Type "Apple_HFS"
    HFS file system
    Volume name "Macintosh HD"
    Volume size 74.53 GiB (800
  • From philo@21:1/5 to Paul on Sun Dec 12 18:15:18 2021
    On 12/12/21 5:23 PM, Paul wrote:
    On 12/12/2021 3:35 PM, philo wrote:

    Asking here because no one on the Mac groups seems to have a clue
    about anything other than hurling insults.


    I recently had to work on a Mac, where the owner had forgotten the
    password. It was one that had a firmware password so I could not use
    any of the normal recovery options.

    I figured all I'd have to do is put the drive in my Linux machine and
    delete /var/db/.AppleSetupDone

    (that will allow the setup of a new administrator account.)


    I was able to view the file but due to the drive being journaled,
    unable to delete it.


    I figured that as long as I had the drive in my machine, I might as
    well backup their data but I was also unable to to that unless I did
    so as root.

    I had to copy the data to a root-owned folder but after I did, and
    even after I changed ownership to my user profile, was unable to copy
    the data to my own profile.


    My question is...what is it about HFS+ , journaled that Linux cannot
    handle...and why?


    I ended up connecting the drive to my old iMac.
    Finally, in order for me to delete .AppleSetupDone, I had to do so
    from the terminal. The file did not appear in the GUI file manager,
    even after I hit the keys to "show hidden."

    Does HFS+ have both hidden and system files in the way DOS and Windows
    do?

    Is the dot in from of the file name and indication of "system?"


    Thanks.


    To do a backup, I did a "dd" on a Mac G4, to keep an archival quality
    image.
    That way, if I screwed up some "more clever" backup method at the time,
    I'd never have to
    go back into the thing.

    Here's a reference to some background info. I doubt it will directly
    answer your questions about manipulations there. You will recognize some familiar concepts when you skim through this.

    https://developer.apple.com/library/archive/technotes/tn/tn1150.html

    Sage advice on messing with journals. Generally, there's a habit amongst foreign file system developers to not support journaling. Which is naughty. It endangers data integrity (like if the file system was uncleanly shut
    down, and you were hoping the journal would be available on the next boot cycle to support proper cleanup). Naturally, this is the antithesis of maintenance people - and their need to write to a volume using a foreign method.

    https://help.ubuntu.com/community/hfsplus

    Be careful with Gparted. I tried to manipulate partitions with
    GParted, and it trashed the drive. But with my backup, I didn't
    particularly care. As, after all, this is how you "dial in" disk
    tools. You test them carefully, for precisely this reason.
    The first time you use a tool, have that "dd" backup salted away
    for safe keeping.

    In Linux, you can use the "disktype" utility on the some.img file
    created by "dd", and it will tell you about the partition structure.
    Using the offset info, you could also attempt a loopback mount
    with offset, and then you would have access to the partition.
    But only if the journal has been handled (somehow) safely.

    --- mac__sda2.img
    Regular file, size 74.53 GiB (80026877952 bytes)
    Apple partition map, 10 entries
    Partition 1: 31.50 KiB (32256 bytes, 63 sectors from 1)
      Type "Apple_partition_map"
    Partition 2: 28 KiB (28672 bytes, 56 sectors from 64)
      Type "Apple_Driver43"
    Partition 3: 28 KiB (28672 bytes, 56 sectors from 120)
      Type "Apple_Driver43"
    Partition 4: 28 KiB (28672 bytes, 56 sectors from 176)
      Type "Apple_Driver_ATA"
    Partition 5: 28 KiB (28672 bytes, 56 sectors from 232)
      Type "Apple_Driver_ATA"
    Partition 6: 256 KiB (262144 bytes, 512 sectors from 288)
      Type "Apple_FWDriver"
      Blank disk/medium
    Partition 7: 256 KiB (262144 bytes, 512 sectors from 800)
      Type "Apple_Driver_IOKit"
      Blank disk/medium
    Partition 8: 256 KiB (262144 bytes, 512 sectors from 1312)
      Type "Apple_Patches"
    Partition 9: 74.53 GiB (80025423872 bytes, 156299656 sectors from 1824)
    <=== fun starts here
      Type "Apple_HFS"
      HFS file system
        Volume name "Macintosh HD"
        Volume size 74.53 GiB (80024608768 bytes, 65342 blocks of 1.168 MiB)
      HFS wrapper for HFS Plus
        HFS Plus file system
          Volume size 74.52 GiB (80018485248 bytes, 19535763 blocks of 4 KiB) Partition 10: 4 KiB (4096 bytes, 8 sectors from 156301480)
      Type "Apple_Free"
      Blank disk/medium

    The disk in the example, was the system drive of that Mac.
    And wasn't particularly modified by me. It's more or less
    in original condition.

    The HFS wrapper is similar to the protective 0xEE partition
    on GPT disks. It's a way of preventing legacy OSes from
    creating partitions using the "old" way. HFS in this case.
    The wrapper "blots out" all the free space, so the older
    OS cannot damage the drive (not without an effort at least).

    Thus, you can see my "Macintosh HD" has two variants. I'm not 100%
    sure the labeling is correct in that stanza, as I think it should
    read HFS Plus for Macintosh HD.

    *******

    Macintosh had resource and data fork at one time. One of those
    is an Alternate Stream. When messing with a disk, you'd have to
    determine whether both forks need to be accessed and so on. If
    a file system happened to have Alternate Streams and the foreign
    mounting method paid scant heed to that (as there was no Alternate
    Streams in the OS to fit it to), then again, you could be doing
    "half a job" when doing things to files.

    https://unix.stackexchange.com/questions/57987/can-i-read-and-write-to-alternate-hfs-file-forks-or-ntfs-data-streams-from-linu


    This would not be a project I would be rushing to finish.

       Paul





    Thanks Paul>
    I was hoping you would reply...that is the reason I posted here.

    I see that I have some reading to to and also some experimenting.

    Will have to dig out a non-journaled HFS+ drive and see how that
    compares to a journaled one from Linux>


    I am sure there was a major inconsistency in the journalling method in
    HFS+ and ext4.
    Maybe I should have experimented by trying to copy the data to an NTFS partition and also Fat32>


    Anyway, journalling is a great thing.

    Years ago I had to perform a data recovery from an NTFS drive that had developed a read/write error that would fail entirely once the drive got
    to a certain temperature.

    After numerous tries, I got 98% of the data copied to another NTFS drive.

    Unfortunately a lot was initially corrupted but miraculously
    self-healed. I would have assumed that nothing in the journal would have transferred to the new drive, yet somehow it must have.

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