gesperrte Dateien auf der HFS + -Home-Partition, die von OSX / Linux gemeinsam genutzt wird

2917
HazyBlueDot

Ich bin auf meinem MacBook Pro doppelt in Arch Linux und OS X 10.6. Ich habe meine UID zwischen beiden Betriebssystemen synchronisiert und eine HFS-Partition (ohne Journaling) erstellt, die als gemeinsam genutzte Home / Users-Partition verwendet werden kann. Meistens funktioniert es genau so, wie ich es mir vorgestellt habe, aber manchmal, wenn ich in OS X gebootet werde, sind bestimmte Dateien "gesperrt" (wenn ich Informationen zu einer bestimmten Datei erhalte, wird das Kästchen "Gesperrt" unter "Allgemein" markiert.) Ich kann das Problem durch manuelles Deaktivieren des Kontrollkästchens beheben) und / oder erhalte die Meldung "Vorgang nicht zulässig", wenn ich versuche, eine Datei zu löschen oder zu chmodieren. In beiden Fällen sehe ich nichts Außergewöhnliches in den Berechtigungsbits, die mit ls -l angezeigt werden, mit Ausnahme eines nachgestellten '@'-Zeichens an der Position, 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, scheint also nicht mit der Berechtigungssituation' locked / operation 'verbunden zu sein.

Auf der Linux-Seite habe ich nie Probleme mit der Berechtigung. Nach meinem begrenzten Wissen und meiner Erfahrung mit ACLs habe ich in keiner der fraglichen Dateien ACLs gefunden.

Für das, was es wert ist, bearbeite ich meine Dateien meistens mit Emacs (Aquamacs in OSX). Kann es sein, dass seltsame Berechtigungsbits gesetzt werden?

  1. Was ist die "gesperrte" Einstellung, die OS X verwendet, und hat ein entsprechendes Berechtigungsbit (so könnte ich zumindest alle Dateien in meinem Home-Verzeichnis vom Terminal rekursiv entsperren)
  2. Warum werden einige, aber nicht andere Dateien beim Booten in OS X "gesperrt"?
  3. Was bedeutet das Zeichen "@"?
4
Ich habe gerade den Befehl "chflags" entdeckt und festgestellt, dass das Element "locked" das Äquivalent zum Setzen / Deaktivieren des Flags uchange darstellt. Ich kann das also zum rekursiven Entsperren meiner Dateien verwenden, bin aber trotzdem neugierig, wie und warum Sie werden in erster Linie gesperrt. HazyBlueDot vor 13 Jahren 0
Erwägen Sie [Deaktivieren der Berechtigungen für das Volume] (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemDetails/FileSystemDetails.html): "Außerdem können Benutzer von OS X Administratoren dies tun Deaktivieren Sie die Besitz- und Berechtigungsprüfung für austauschbare Datenträger auf Datenträgerbasis, indem Sie im Finder auf dem Datenträger die Option Informationen anzeigen wählen und dann das Kontrollkästchen "Besitz auf diesem Datenträger ignorieren" aktivieren. " (aus der Apple-Dokumentation) ignis vor 11 Jahren 0

4 Antworten auf die Frage

5
oluc

Ich bin auch auf die gleiche Frage gestoßen.

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

Flaggen werden angezeigt mit:

$ ls -laO / Volumes / mein-Volume

Flags können rekursiv entfernt werden mit:

$ man chflags

$ chflags -R nouchg, nouappnd, noopaque, dump / Volumes / my-volume

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

Tolles Rezept - hat mir geholfen! akauppi vor 11 Jahren 1
3
Spiff

Das @bedeutet, dass die Datei "erweiterte Attribute" (zusätzliche Metadaten, abgekürzt "xattrs") im Dateisystem angehängt ist. Unter ls -l@Mac OS X können Sie die Liste der an die Dateien angehängten Xattrs anzeigen.

Classic Mac OS hatte das Konzept von "Finder Info", einem kleinen festen (nicht erweiterbaren) Satz von Metadaten, den alle Dateien auf einem HFS-Volume hatten. Dazu gehörten die "Typ- und Erstellercodes" und die "Finder-Flags", darunter das gesperrte Bit, das "sichtbare" (verborgene) Bit und mehrere andere. Mac OS X hat im Grunde die alten Finder-Metadaten verworfen. In den Fällen, in denen sie noch benötigt werden, werden sie jetzt als xattr an den Datensatz der Datei im Dateisystem angehängt. Bei den gesperrten Dateien, die Sie sehen, ist dieses Finder info xattr fast sicher angebracht, sodass der Status des alten gesperrten Finder-Bits aufgezeichnet werden kann.

Mein Snow Leopard-System hat einen /usr/bin/xattrBefehl, der anscheinend keine Manpage hat, er hat jedoch eine Verwendungsanweisung, wenn Sie ihn mit aufrufen -h. Beachten Sie, dass xattr -l filenamedies nützlich sein kann, um einen hexadezimalen / ASCII-Speicherauszug der Werte der an eine Datei angehängten xattrs zu erhalten.

Zu den in Mac OS X integrierten Befehlen zum Anzeigen und Bearbeiten des alten Finder Info xattr vom Terminal gehören GetFileInfo(1)und SetFile(1).

Update:
Ich habe keine gute Erklärung dafür, warum diese Dateien gesperrt werden. Meine Vermutung wäre jedoch, dass die HFS-Unterstützungssoftware, die Sie unter Linux ausführen, entweder den Zweck und den Status des alten Finder-Sperrbits und die entsprechende Einstellung falsch versteht Wenn es nicht der Fall sein sollte, oder es verwendet das Sperrbit absichtlich als Mechanismus, um ein semantisches Konzept eines Linux-Dateisystems auf HFS abzubilden.

Das Finder-Sperrbit war für Benutzer gedacht, um ihre eigenen Dateien manuell zu sperren, sodass sie nicht versehentlich geändert oder gelöscht wurden. Sie waren nicht als Mechanismus für das Sperren von Dateien auf Prozessebene gedacht, um zu vermeiden, dass mehrere Prozesse in dieselbe Datei schreiben zur selben Zeit. Das heißt, es sollte kein Ersatz für fcntl(2)oder sein 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-Sperrbit missbraucht, um die Dateisperrenwünsche von emacs auszuführen.

3
Frank Ganske

I've found a workaround. It's seems to be a race condition in the hfsplus kernel module, caused by non atomic access to userflags. I've disabled it and the userflags will ever be zero, unlocked, ok for me.

fs/hfsplus/inode.c near line 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 near line 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);

You could build a custom kernel, but I use 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 $ SUBDIRS=$/$/$/build modules" BUILT_MODULE_NAME[0]="hfsplus" DEST_MODULE_LOCATION[0]="/kernel/fs/hfsplus" REMAKE_INITRD=y AUTOINSTALL="yes"

Note: The installation fails for me, if I don't cd into /usr/src .

To uninstall:

# dkms remove hfsplus/YOUR_VERSION --all

Environment: 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.

Hast du das irgendwie Upstream gemeldet? Ich glaube, ich habe das gleiche Problem. Blaisorblade vor 12 Jahren 0
Update: Der Fehler ist in Linux 3.4 behoben. Der korrekte Fix ist hier: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f3922382ce930e76773fb06416a7a6081a8702ad Blaisorblade vor 12 Jahren 0
Wow, erster Korrektur-Patch, den ich als SO / SU-Antwort gesehen habe. Kudos akauppi vor 11 Jahren 0
@FrankGanske: Nur um zu klären: Der Fix "funktioniert", unterscheidet sich jedoch vom offiziellen und könnte Nachteile haben (ich denke, es würde absichtlich verhindern, dass "userflags" geändert werden, wie die Antwort bestätigt). Blaisorblade vor 11 Jahren 0
1
Blaisorblade

Dies ist ein Linux-Kernel-Fehler, der in 3.4 ( Patch ) behoben wurde .

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-Repositorys (und ich bezweifle, dass git dies tun würde). Sie können diese Attribute mit sehen ls -lO. Wenn Sie dies für meine Sicherung tun, zeigen Sie, 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 dies mit demselben Verzeichnis in einem Arbeitsdateisystem verglichen, und diese Bits sind nicht gesetzt.

Verwandte Probleme