Câu hỏi tệp bị khóa trên phân vùng HFS + home được chia sẻ giữa OSX / Linux


Tôi khởi động kép vào Arch Linux và OS X 10.6 trên MacBook pro của tôi. Tôi đồng bộ hóa UID của tôi giữa cả hai hệ điều hành và tạo ra một phân vùng HFS (không có journaling) để sử dụng như một phân vùng home / Users chia sẻ. Đối với hầu hết các phần nó hoạt động giống như tôi mong đợi, nhưng đôi khi khi tôi khởi động vào OS X một số tập tin được "khóa" (khi tôi nhận được thông tin về một tập tin cụ thể, "Locked" hộp được kiểm tra theo "General" Tôi có thể giải quyết vấn đề bằng cách bỏ chọn hộp kiểm thủ công) và / hoặc tôi nhận được "Hoạt động không được phép" khi tôi thử xóa hoặc chmod'ing một tệp. Trong cả hai trường hợp, tôi không thấy bất kỳ điều gì ngoài thông thường trên các bit quyền được hiển thị với ls -l, ngoại trừ ký tự '@' ở vị trí có bit dính thường xảy ra:

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

Ký tự '@' này hiển thị trên TẤT CẢ các tệp bình thường, do đó dường như không được liên kết với tình trạng khóa / hoạt động không được phép.

Về phía Linux của những thứ tôi không bao giờ có vấn đề về quyền. Theo hiểu biết và kinh nghiệm hạn chế nhất của tôi với ACL, tôi đã không tìm thấy bất kỳ ACL nào trên bất kỳ tệp nào được đề cập đến.

Đối với những gì nó có giá trị, tôi làm hầu hết các chỉnh sửa tập tin của tôi bằng cách sử dụng emacs (Aquamacs trong OSX), là nó có thể nó là thiết lập bit cho phép lạ?

  1. Cài đặt "bị khóa" mà OS X sử dụng là gì và nó có tương đương bit quyền hay không (vì vậy ít nhất tôi có thể mở khóa đệ quy tất cả các tệp trong thư mục chính của mình từ thiết bị đầu cuối)
  2. tại sao có thể một số, nhưng không phải các tệp khác bị "khóa" khi khởi động vào OS X
  3. ý nghĩa của ký tự '@' là gì?

4
2018-05-17 16:22


gốc


cập nhật nhanh chóng, tôi vừa phát hiện ra lệnh "chflags" và mục "bị khóa" tương đương với cài đặt / hủy đặt cờ uchange, vì vậy tôi có thể sử dụng để mở khóa đệ quy các tệp của mình, nhưng tôi vẫn tò mò về cách / tại sao họ đang bị khóa ở nơi đầu tiên. - HazyBlueDot
Xem xét vô hiệu hóa quyền cho khối lượng: "Ngoài ra, OS X cho phép người dùng quản trị vô hiệu hóa quyền sở hữu và quyền kiểm tra khối lượng di động trên cơ sở mỗi khối lượng bằng cách chọn Nhận thông tin trên ổ đĩa trong Trình tìm kiếm, sau đó chọn hộp kiểm" Bỏ qua quyền sở hữu trên ổ đĩa này ". (từ tài liệu của Apple) - ignis


Các câu trả lời:


Tôi cũng đang gặp vấn đề tương tự.

Sự hiểu biết của tôi từ thông tin mà tôi đọc ở đây, và ở những nơi khác, đó là một lỗi hạt nhân Linux trong mô-đun hfsplus. Nó thêm cờ người dùng ngẫu nhiên vào tệp. Có hai cờ ngăn chặn việc chỉnh sửa / xóa các tập tin: uchg và uappnd. Đây là hai kẻ xấu. Chúng có thể được áp dụng cho một tệp hoặc thậm chí là một thư mục cha.

Cờ được hiển thị với:

$ ls -laO / Âm lượng / âm lượng của tôi

Cờ có thể được loại bỏ đệ quy với:

$ man chflags

$ chflags -R nouchg, nouappnd, noopaque, dump / Khối lượng / âm lượng của tôi

LƯU Ý: Tôi cũng loại bỏ các cờ đục và cờ gật đầu. Tôi không cần cờ.


5
2017-09-21 15:23



Công thức tuyệt vời - đã giúp tôi! - akauppi


Các @ có nghĩa là tệp đó có "thuộc tính mở rộng" (siêu dữ liệu bổ sung, viết tắt là "xattrs") được đính kèm với tệp đó trong hệ thống tệp. Để xem danh sách các xattrs gắn liền với các tập tin, hãy làm ls -l@ trong Mac OS X.

Mac OS cổ điển có khái niệm "Thông tin tìm kiếm" là bộ siêu dữ liệu cố định (không thể mở rộng) nhỏ mà tất cả các tệp trên ổ đĩa HFS đều có. Điều này bao gồm "loại và mã người tạo" và "Cờ tìm kiếm", bao gồm cả bit "bị khóa", bit "hiển thị" (ẩn) và một số thứ khác. Mac OS X về cơ bản đã không sử dụng siêu dữ liệu Finder cũ, nhưng vào những dịp mà nó vẫn còn cần thiết, nó bây giờ được gắn vào hồ sơ của tập tin trong hệ thống tập tin như một xattr. Những tập tin bị khóa bạn đang nhìn thấy gần như chắc chắn có thông tin Finder này xattr đính kèm, để trạng thái của Finder cũ "bị khóa" bit có thể được ghi lại.

Hệ thống Snow Leopard của tôi có /usr/bin/xattr lệnh mà dường như không có trang người đàn ông, nhưng nó có một tuyên bố sử dụng nếu bạn gọi nó với -h. Lưu ý rằng xattr -l filename có thể hữu ích để có được một kết xuất hex / ASCII của các giá trị của xattrs gắn liền với một tệp.

Các lệnh cài sẵn của Mac OS X để xem và thao tác thông tin Finder cũ xattr từ terminal bao gồm GetFileInfo(1) và SetFile(1).

Cập nhật:
Tôi không có lời giải thích nào về lý do tại sao các tệp đó bị khóa, nhưng linh cảm của tôi là bất kỳ phần mềm hỗ trợ HFS nào bạn đang chạy trong Linux đều hiểu sai mục đích, và trạng thái không được chấp nhận, của bit khóa Finder cũ và thiết lập nó khi nó không nên, hoặc nó cố ý sử dụng bit khóa như một cơ chế để ánh xạ một số loại khái niệm ngữ nghĩa hệ thống tập tin Linux lên HFS.

Bit khóa Finder được thiết kế như một cách để người dùng tự khóa các tệp của riêng họ để họ không vô tình sửa đổi hoặc xóa chúng và không phải có nghĩa là một cơ chế để khóa tệp mức quy trình để tránh nhiều quá trình ghi vào cùng một tệp tại cùng một thời điểm. Đó là, nó không phải là một sự thay thế cho fcntl(2) hoặc là flock(2). Tại thời điểm bit khóa Finder được thiết kế, máy Mac không phải là một hệ thống đa xử lý.

Cập nhật 2: Nó cũng có thể là Aquamacs đang lạm dụng bit khóa Finder cũ để thực hiện mong muốn khóa tập tin của emacs.


3
2018-05-17 18:41





Tôi đã tìm được cách giải quyết. Nó có vẻ là một điều kiện chủng tộc trong mô-đun hạt nhân hfsplus, gây ra bởi truy cập không nguyên tử vào userflags. Tôi đã vô hiệu hóa nó và các userflags sẽ không bao giờ, mở khóa, ok cho tôi.

fs / hfsplus / inode.c gần dòng 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 gần dòng 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);

Bạn có thể xây dựng một hạt nhân tùy chỉnh, nhưng tôi sử dụng 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"

Lưu ý: Việc cài đặt không thành công cho tôi, nếu tôi không cd vào / usr / src.

Để gỡ cài đặt:

# dkms remove hfsplus/YOUR_VERSION --all

Môi trường: MacBookPro7,1, Core 2 Duo, SATA NVidia MCP89 AHCI, Mac OS X 10.6, Debian GNU / Linux, hạt nhân 2.6.28, 2.6.29, 3.0, 3.1, 3.2.


3
2017-08-04 12:24



Bạn đã báo cáo ngược dòng này chưa? Tôi nghĩ rằng tôi đang chạy vào cùng một vấn đề. - Blaisorblade
Cập nhật: lỗi được sửa trong Linux 3.4. Sửa chữa chính xác là ở đây: git.kernel.org/?p=linux/kernel/git/torvalds/… - Blaisorblade
Wow, bản vá sửa lỗi đầu tiên tôi đã xem như là một câu trả lời SO / SU. Thanh danh. - akauppi
@ FrankGanske: Chỉ cần làm rõ: bản sửa lỗi "hoạt động", nhưng khác với bản chính thức và có thể có nhược điểm (tôi đoán nó sẽ ngăn thay đổi userflags về mục đích, như câu trả lời thừa nhận). - Blaisorblade


Đây là lỗi hạt nhân Linux, được khắc phục trong 3.4 ().

Tôi đã có cùng một vấn đề bằng cách sử dụng các tiện ích Unix thuần túy. Cụ thể, tôi đã sao lưu ổ cứng Mac OS X của mình từ Xubuntu 12.04 trực tiếp bằng rsync. Sau khi khôi phục, nhiều thư mục bị khóa ngẫu nhiên, bao gồm các thư mục trong kho git (và tôi rất nghi ngờ git sẽ làm điều đó). Bạn có thể thấy những người thu thập với ls -lO. Làm điều đó trên bản sao lưu của tôi cho thấy rằng các bit này có các giá trị cơ bản ngẫu nhiên:

# 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

Tôi đã so sánh điều này với cùng một thư mục trên một hệ thống tập tin làm việc, và những bit đó không được thiết lập.


1
2017-09-09 15:52