Tại sao lưu trữ các liên kết tự và cha mẹ (. Và ..) trong một mục nhập thư mục?

Hãy xem xét một hệ thống tệp được nhắm mục tiêu vào một số thiết bị nhúng không chỉ lưu trữ các tệp trong cấu trúc thư mục phân cấp. Hệ thống tệp này thiếu nhiều thao tác bạn có thể sử dụng trong các hệ thống như unix và Windows (ví dụ: quyền truy cập của nó hoàn toàn khác nhau và không bị ràng buộc với siêu dữ liệu được lưu trữ trong các thư mục). Hệ thống tệp này không cho phép bất kỳ loại liên kết cứng hoặc liên kết mềm nào, vì vậy mỗi tệp có một tên duy nhất trong cấu trúc cây nghiêm ngặt.

Có bất kỳ lợi ích nào khi lưu trữ một liên kết đến chính thư mục và đến cha mẹ của nó trong cấu trúc dữ liệu trên đĩa đại diện cho một thư mục không?

Hầu hết các hệ thống tập tin unix có .và ..các mục trên đĩa. Tôi tự hỏi tại sao họ không xử lý những người ở lớp VFS (trình điều khiển hệ thống tập tin chung). Đây có phải là một cổ vật lịch sử? Có một lý do chính đáng, và nếu vậy, chính xác, vì vậy tôi có thể xác định liệu nó có liên quan đến hệ thống nhúng của mình không?

Có liên kết đến thư mục cha mẹ có ý nghĩa tốt với tôi. Nếu bạn không có chúng, bạn sẽ luôn cần phải làm việc với toàn bộ danh sách các thư mục. Vì vậy, ví dụ, /home/svick/Documents/sẽ phải được đại diện là { /, /home/, /home/svick/, /home/svick/Documents }. Nếu bạn không làm điều đó, bạn sẽ không thể tìm thấy thư mục mẹ (hoặc nó sẽ rất tốn kém). Điều này không chỉ không hiệu quả, mà còn nguy hiểm. Nếu bạn có hai danh sách trùng nhau như vậy, chúng có thể dễ dàng đồng bộ hóa nếu bạn di chuyển một số thư mục.

Mặt khác, nếu bạn có một tham chiếu đến thư mục mẹ, nó sẽ hiệu quả và an toàn hơn.

Tôi không thấy bất kỳ lý do để thực sự có một liên kết đến thư mục hiện tại. Nếu bạn có một cấu trúc đại diện cho một số thư mục và bạn muốn truy cập vào thư mục đó, việc sử dụng .luôn hoàn toàn không cần thiết. Do đó, tôi hy vọng rằng .liên kết không thực sự tồn tại trong cấu trúc hệ thống tập tin và chỉ là ảo.

Bạn nhận được ít trường hợp đặc biệt. Trong nhiều tình huống, VFS có thể xử lý ".." vì nó xử lý bất kỳ tên thư mục nào khác.

Lý do duy nhất tôi có thể tưởng tượng là kịch bản sau đây:

1. Một triển khai ban đầu của một hệ thống tệp tồn tại với cùng định dạng thư mục nhưng các khái niệm về đường dẫn tệp và thư mục con không được xem xét tại thời điểm đó (Xem Hệ thống tệp PDP-7 Unix ).

2. Sau đó mọi người nghĩ rằng giải pháp đường dẫn và thư mục con sẽ hữu ích!

3. Để giữ một số lượng tương thích ngược với các triển khai cũ hơn, người ta đã quyết định rằng .và ..sẽ được lưu trữ trên đĩa giống như bất kỳ thư mục nào khác.

Vì vậy, có lẽ chúng ta còn lại với những đồ tạo tác vô dụng đó, chỉ vì khả năng tương thích ngược với phần mềm 40 năm tuổi? Kịch bản đáng tin cậy?

Lưu ý: Ngoài ra, việc thêm các mục này vào danh sách thư mục không phải là hoàn toàn ngu ngốc, vì dù sao bạn cũng cần lưu trữ số inode của thư mục cha mẹ thực sự của mình (hãy nhớ rằng các liên kết cứng trên thư mục được cho phép) và tham chiếu đến số inode riêng có thể là một kiểm tra vệ sinh tốt.

Tôi không thấy một lý do để thực hiện .và ..ở cả hai cấp độ hơn là ở cấp độ khác. Tuy nhiên, nếu bạn nhắm mục tiêu các hệ thống nhúng, bất kỳ lớp nào bạn có thể tiết kiệm có thể kiếm được bằng đô la, do đó, có thể có ý nghĩa khi thử và triển khai mọi thứ ở mức thấp nhất có thể.

Đối với nhu cầu chung của .và .., làm thế nào bạn thể hiện các đường dẫn tương đối mà không có chúng? Ít nhất ..là không thể thiếu cho các đường dẫn rời khỏi cây con hiện tại. Nếu bạn không cần các đường dẫn như vậy (có thể cây là một cách nguyên thủy để mã hóa các đặc quyền truy cập?) Thì bạn không cần ...