Frage Gesperrte Dateien auf HFS + Home-Partition, die unter OSX / Linux freigegeben sind


Ich bin Dual-Boot in Arch Linux und OS X 10.6 auf meinem MacBook Pro. Ich habe meine UID zwischen beiden Betriebssystemen synchronisiert und eine HFS-Partition (ohne Journaling) erstellt, die ich als Shared Home / Users-Partition verwenden kann. Zum größten Teil funktioniert es genau so wie ich es erwarte, aber manchmal, wenn ich in OS X gebootet werde, sind bestimmte Dateien "gesperrt" (wenn ich Informationen über eine bestimmte Datei erhalte, wird das "Gesperrt" Feld unter "Allgemein" angeklickt) Ich kann das Problem lösen, indem ich die Box manuell deaktiviere) und / oder ich bekomme "Operation nicht erlaubt", wenn ich versuche, eine Datei zu löschen oder zu chmodieren. In beiden Fällen sehe ich nichts Außergewöhnliches an den Berechtigungsbits, die mit ls -l angezeigt werden, mit Ausnahme eines nacheilenden '@' - Zeichens an der Stelle, an der das Sticky-Bit normalerweise auftreten würde:

-rw-r--r--@  1 myuser  mygroup   296 Mar 29 11:44 myfile

Dieses '@' Zeichen erscheint in ALLEN normalen Dateien, daher scheint es nicht mit der gesperrten / Operation nicht Berechtigungssituation verbunden zu sein.

Auf der Linux-Seite der Dinge habe ich nie Berechtigungsprobleme. Nach meinem besten Wissen und meiner Erfahrung mit ACLs habe ich keine ACLs in den fraglichen Dateien gefunden.

Für was es wert ist, mache ich die meisten meiner Dateibearbeitung mit Emacs (Aquamacs in OSX), ist es möglich, dass es seltsame Erlaubnis Bits setzt?

  1. Was ist die "gesperrte" Einstellung, die OS X verwendet und hat ein entsprechendes Berechtigungsbit (so könnte ich rekursiv alle Dateien in meinem Home-Verzeichnis vom Terminal aus entsperren)
  2. Warum können einige, aber nicht andere Dateien beim Booten in OS X "gesperrt" werden
  3. Was bedeutet das Zeichen "@"?

4
2018-05-17 16:22


Ursprung


schnelles update, ich habe gerade den "chflags" -Befehl entdeckt und das "locked" -Element entspricht dem Setzen / Deaktivieren des uchange-Flags, also kann ich damit meine Dateien rekursiv entsperren, bin aber trotzdem neugierig wie / warum sie werden erst einmal eingesperrt. - HazyBlueDot
Erwägen Deaktivieren der Berechtigungen für das Volume: "Darüber hinaus ermöglicht OS X Admin-Benutzern das Deaktivieren von Besitzrechten und Berechtigungen zum Prüfen auf austauschbare Volumes pro Volume, indem Sie im Finder die Option Informationen auf dem Volume auswählen und dann das Kontrollkästchen" Eigentumsrechte für dieses Volume ignorieren "aktivieren. (aus der Apple-Dokumentation) - ignis


Antworten:


Ich bin auch auf dasselbe Problem gestoßen.

Mein Verständnis von Informationen, die ich hier und an anderen Stellen gelesen habe, ist, dass es sich um einen Linux-Kernel-Bug im hfsplus-Modul handelt. Es fügt zufällige Benutzerflags zu Dateien hinzu. Es gibt zwei Flags, die das Bearbeiten / Löschen von Dateien verhindern: uchg und uappnd. Das sind die zwei bösen Jungs. Sie können auf eine Datei oder sogar auf ein übergeordnetes Verzeichnis angewendet werden.

Flags werden angezeigt mit:

$ ls -laO / Volumen / mein Volumen

Flags können rekursiv entfernt werden mit:

$ mann chflags

$ chflags -R nouchg, noappend, noopaque, dump / Volumen / mein Volumen

HINWEIS: Ich entferne auch die opaken und nodump Flags. Ich brauche keine Flaggen.


5
2017-09-21 15:23



Tolles Rezept - hat mir geholfen! - akauppi


Das @ bedeutet, dass die Datei "erweiterte Attribute" (zusätzliche Metadaten, abgekürzt "xattrs") im Dateisystem angehängt hat. Um die Liste der an die Dateien angehängten Xatrs zu sehen, machen Sie ls -l@ in Mac OS X.

Klassisches Mac OS hatte das Konzept "Finder Info", das eine kleine feste (nicht erweiterbare) Menge von Metadaten war, die alle Dateien auf einem HFS-Volume hatten. Dazu gehörten die "Typ- und Erstellercodes" und die "Finder-Flags", einschließlich des "gesperrten" Bits, des "sichtbaren" (versteckten) Bits und einiger anderer. Mac OS X hat die alten Finder-Metadaten grundsätzlich veraltet, aber wenn es noch benötigt wird, wird es jetzt als XATTR an den Datensatz der Datei im Dateisystem angehängt. Die gesperrten Dateien, die Sie sehen, haben mit ziemlicher Sicherheit diese Finder-Info xattr angehängt, so dass der Status des alten "Finder" -Bits des Finders aufgezeichnet werden kann.

Mein Snow Leopard System hat eine /usr/bin/xattr Befehl, der keine Manpage zu haben scheint, aber eine Usage-Anweisung, wenn Sie sie aufrufen -h. Beachten Sie, dass xattr -l filename kann nützlich sein, um einen Hex / ASCII-Dump der Werte der xattrs zu erhalten, die an eine Datei angehängt sind.

Die integrierten Befehle von Mac OS X zum Anzeigen und Bearbeiten der alten Finder-Informationen xattr vom Terminal umfassen GetFileInfo(1) und SetFile(1).

Aktualisieren:
Ich habe keine gute Erklärung dafür, warum diese Dateien gesperrt werden, aber meine Vermutung ist, dass jede HFS-Unterstützungssoftware, die Sie unter Linux ausführen, entweder den Zweck und den veralteten Status des alten Finder-Sperrbits missversteht und es dann setzt Es sollte nicht oder absichtlich das Sperrbit als Mechanismus verwenden, um irgendeine Art von semantischem Linux-Dateisystem-Konzept auf HFS abzubilden.

Das Finder-Lock-Bit war als eine Möglichkeit für Benutzer gedacht, ihre eigenen Dateien manuell zu sperren, so dass sie nicht versehentlich geändert oder gelöscht wurden nicht Als Mechanismus zum Sperren von Dateien auf Prozessebene gedacht, um zu vermeiden, dass mehrere Prozesse gleichzeitig in dieselbe Datei geschrieben werden. Das heißt, es sollte kein Ersatz sein fcntl(2) oder flock(2). Zu der Zeit, als das Finder-Lock-Bit entworfen wurde, war der Mac kein Multiprocessing-System.

Update 2: Es könnte auch sein, dass Aquamacs das alte Finder-Lock-Bit missbraucht, um die Dateisperrwünsche von Emacs auszuführen.


3
2018-05-17 18:41





Ich habe einen Workaround gefunden. Es scheint sich um eine Race-Bedingung im hfsplus-Kernel-Modul zu handeln, die durch nicht-atomaren Zugriff auf userflags verursacht wird. Ich habe es deaktiviert und die userflags werden jemals Null sein, entsperrt, ok für mich.

fs / hfsplus / inode.c nahe Zeile 248:

    inode->i_mode = mode;

/* FIXME commented out because of unreliable results, needs mutex_lock (?) */
//    HFSPLUS_I(inode)->userflags = perms->userflags;
    if (perms->rootflags & HFSPLUS_FLG_IMMUTABLE)

fs / hfsplus / catalog.c in der Nähe von Zeile 79:

            perms->rootflags &= ~HFSPLUS_FLG_APPEND;

/* FIXME commented out because of unreliable results, needs mutex_lock (?) */
//    perms->userflags = HFSPLUS_I(inode)->userflags;
    perms->mode = cpu_to_be16(inode->i_mode);

Sie könnten einen benutzerdefinierten Kernel erstellen, aber ich verwende dkms:

$ cd /usr/src
$ tar xjpvf linux-source-*.tar.bz2 linux-source-*/fs/hfsplus
$ cp -R linux-source-*/fs/hfsplus hfsplus-YOUR_VERSION
$ vi hfsplus-YOUR_VERSION/inode.c
$ vi hfsplus-YOUR_VERSION/catalog.c
$ vi hfsplus-YOUR_VERSION/dkms.conf (see below for the content)
$ su
# dkms install hfsplus/YOUR_VERSION

/usr/src/hfsplus-YOUR_VERSION/dkms.conf:

NAME=hfsplus
VERSION=YOUR_VERSION
PACKAGE_NAME="$NAME"
PACKAGE_VERSION="$VERSION"
MAKE[0]="make -C ${kernel_source_dir}
  SUBDIRS=${dkms_tree}/${NAME}/${VERSION}/build modules"
BUILT_MODULE_NAME[0]="hfsplus"
DEST_MODULE_LOCATION[0]="/kernel/fs/hfsplus"
REMAKE_INITRD=y
AUTOINSTALL="yes"

Hinweis: Die Installation schlägt für mich fehl, wenn ich nicht in / usr / src cd.

So deinstallieren Sie:

# dkms remove hfsplus/YOUR_VERSION --all

Umgebung: MacBookPro7,1, Core 2 Duo, SATA NVidia MCP89 AHCI, Mac OS X 10.6, Debian GNU / Linux, Kernel 2.6.28, 2.6.29, 3.0, 3.1, 3.2.


3
2017-08-04 12:24



Hast du diesen Upstream irgendwie gemeldet? Ich denke, ich stoße auf das gleiche Problem. - Blaisorblade
Update: Der Fehler ist in Linux 3.4 behoben. Die richtige Lösung ist hier: git.kernel.org/?p=linux/kernel/git/torvalds/... - Blaisorblade
Wow, der erste korrektive Patch, den ich als SO / SU-Antwort gesehen habe. Kudos. - akauppi
@FrankGanske: Nur um zu verdeutlichen: Der Fix "funktioniert", aber unterscheidet sich von dem offiziellen und könnte Nachteile haben (ich denke, es würde Änderungen verhindern) userflags absichtlich, wie die Antwort anerkennt). - Blaisorblade


Dies ist ein Linux-Kernel-Bug, behoben in 3.4 (patch).

Ich hatte das gleiche Problem mit reinen Unix-Dienstprogrammen. Ich habe nämlich meine Mac OS X-Festplatte von Xubuntu 12.04 live mit rsync gesichert. Nach der Wiederherstellung wurden viele Ordner nach dem Zufallsprinzip gesperrt, einschließlich der Verzeichnisse in Git-Repositories (und ich bezweifle stark, dass git das tun würde). Sie können diese Attribute mit sehen ls -lO. Wenn ich das auf meinem Backup mache, zeigt das, dass diese Bits im Wesentlichen zufällige Werte haben:

# ls -ldO /Volumes/HFS+Backup/Users/pgiarrusso/*
drwx------   31 pgiarrusso  staff  uchg,nodump,opaque         1054 Aug 13 02:00 /Volumes/HFS+Backup/Users/pgiarrusso/Desktop
drwx------   36 pgiarrusso  staff  nodump                     1224 Jul 22 16:04 /Volumes/HFS+Backup/Users/pgiarrusso/Documents
drwx------  108 pgiarrusso  staff  uappnd                     3672 Aug 13 11:43 /Volumes/HFS+Backup/Users/pgiarrusso/Downloads
drwx------   13 pgiarrusso  staff  uappnd,uchg,opaque          442 Jul 22 05:04 /Volumes/HFS+Backup/Users/pgiarrusso/Dropbox
drwx------   53 pgiarrusso  staff  -                          1802 Aug 12 00:58 /Volumes/HFS+Backup/Users/pgiarrusso/Library
drwx------   11 pgiarrusso  staff  uchg,nodump,opaque          374 Jul 22 17:25 /Volumes/HFS+Backup/Users/pgiarrusso/Movies
drwx------   13 pgiarrusso  staff  uappnd,uchg,nodump          442 Jun 10 12:05 /Volumes/HFS+Backup/Users/pgiarrusso/Music
drwx------   15 pgiarrusso  staff  uappnd,nodump,opaque        510 Jun 10 12:05 /Volumes/HFS+Backup/Users/pgiarrusso/Pictures
drwxr-x---   11 pgiarrusso  staff  opaque                      374 Jul  6 15:33 /Volumes/HFS+Backup/Users/pgiarrusso/Public
drwxr-xr-x   34 pgiarrusso  staff  uappnd,uchg,opaque         1156 May 27 12:39 /Volumes/HFS+Backup/Users/pgiarrusso/Sites
drwxr-xr-x    2 pgiarrusso  staff  uappnd,nodump,opaque         68 Jun 10 21:43 /Volumes/HFS+Backup/Users/pgiarrusso/VirtualBox VMs
-rwxr-xr-x    1 pgiarrusso  staff  uappnd,nodump,opaque       1703 Feb 19  2012 /Volumes/HFS+Backup/Users/pgiarrusso/bash-prompt.sh
drwxr-xr-x   22 pgiarrusso  staff  -                           748 Aug 10 19:47 /Volumes/HFS+Backup/Users/pgiarrusso/bin
lrwxrwxrwx    1 pgiarrusso  staff  nodump,opaque                37 Sep 27  2011 /Volumes/HFS+Backup/Users/pgiarrusso/default.sfx -> /Users/pgiarrusso/opt/rar/default.sfx
-rw-r--r--    1 pgiarrusso  staff  uappnd,uchg          1375563169 Aug  2 18:52 /Volumes/HFS+Backup/Users/pgiarrusso/heapdump-1343925310626.hprof
drwxr-xr-x   22 pgiarrusso  staff  uappnd,nodump               748 Aug  1 22:15 /Volumes/HFS+Backup/Users/pgiarrusso/opt
drwxr-xr-x    7 pgiarrusso  staff  uappnd                      238 Apr 19 20:00 /Volumes/HFS+Backup/Users/pgiarrusso/share
drwxr-xr-x   35 pgiarrusso  staff  nodump,opaque              1190 Aug 10 00:06 /Volumes/HFS+Backup/Users/pgiarrusso/tmp

Ich habe das mit demselben Verzeichnis in einem funktionierenden Dateisystem verglichen, und diese Bits sind nicht gesetzt.


1
2017-09-09 15:52