Hard link và symbolic link trên Linux: Hiểu đúng trước khi dùng

Hai tên file có thể cùng dẫn tới một nội dung, nhưng cách chúng liên kết quyết định điều gì xảy ra khi đổi tên, thay thế hoặc xóa một đường dẫn. Trên Linux, hard link và symbolic link giải quyết hai nhu cầu khác nhau; nhầm lẫn có thể khiến bản “sao lưu” thay đổi theo file đang làm việc.

Bài viết giải thích cho file thông thường trên Linux với GNU Coreutils. Lệnh quan sát bên dưới không sửa dữ liệu. Ví dụ tạo liên kết chỉ dùng trong thư mục thử riêng và không cần sudo.

1. Hard link là thêm tên, không phải thêm bản sao

Theo GNU Coreutils, hard link là một tên khác cho cùng file, dùng chung inode trong cùng filesystem. Không có một đường dẫn “gốc” đặc biệt hơn các tên còn lại. Hard link thông thường không vượt qua ranh giới filesystem và không dùng để liên kết thư mục theo cách người dùng thường tạo file link.

Ví dụ tư duy: report.txt và report-hard.txt cùng chỉ tới một file. Nếu ứng dụng sửa trực tiếp nội dung file đó, cả hai tên đều nhìn thấy dữ liệu mới. Vì vậy, tạo hard link không cung cấp một bản sao độc lập để khôi phục khi nội dung bị ghi sai.

2. Symbolic link lưu đường dẫn đích

Tài liệu symlink của Linux mô tả symbolic link là file đặc biệt chứa đường dẫn tới đối tượng khác. Nó có thể trỏ sang filesystem khác hoặc tới một đích chưa tồn tại. Đích tương đối được diễn giải từ thư mục chứa liên kết, không phải từ thư mục hiện tại của người đang đọc.

3. Quan sát trước khi thao tác

Trong thư mục thử, giả sử đã có file nhỏ report.txt và hai tên đích dưới đây chưa tồn tại. Hai lệnh tạo liên kết là:

ln report.txt report-hard.txt
ln -s report.txt report-soft.txt
ls -li -- report.txt report-hard.txt report-soft.txt
readlink -- report-soft.txt

Kết quả kỳ vọng: hai tên hard link có cùng số inode trong cùng filesystem; dòng symlink hiển thị đích report.txt. Số inode thực tế tùy máy, không sao chép một con số mẫu để đối chiếu. readlink đọc chuỗi đích, không chứng minh đích tồn tại hoặc người dùng có quyền mở nó.

Không thêm -f khi gặp báo tên đã tồn tại chỉ để ép lệnh chạy. Kiểm tra đúng thư mục và mục tiêu trước. Bài viết không yêu cầu xóa file để làm minh họa.

4. Vì sao lưu file có thể làm hai tên khác nội dung?

Đây là bẫy đáng chú ý khi kiểm thử bằng trình soạn thảo. “Save” có thể sửa file hiện có, nhưng cũng có thể tạo file tạm rồi đổi tên thay thế đường dẫn cũ. Cách thứ hai làm đường dẫn được thay thế trỏ sang file mới, trong khi hard link còn lại vẫn trỏ file cũ.

Vì vậy, nếu kết quả khác dự đoán, hãy xem ứng dụng lưu theo cách nào thay vì kết luận hard link không hoạt động. Symlink cũng cần được đánh giá theo hành vi của công cụ: công cụ đang theo liên kết để sửa đích, hay đang thay thế chính mục liên kết?

5. Áp dụng trong vận hành

Symlink có thể cung cấp đường dẫn ổn định tới một thư mục phiên bản ứng dụng. Nhưng đổi link không tự giải quyết tiến trình đang giữ file cũ, cache, migration database hoặc việc restart service. Nếu dùng trong deploy, cần kiểm thử toàn bộ quy trình thay vì chỉ kiểm tra lệnh tạo link thành công.

Với sao lưu hoặc đồng bộ, đọc tùy chọn của công cụ: lưu chính liên kết, đi theo đích, hay bảo toàn quan hệ hard link là các hành vi khác nhau. Không dùng đường dẫn do người không tin cậy kiểm soát làm nơi ghi file đặc quyền; liên kết có thể làm vị trí ghi thực tế khác điều nhìn thấy từ tên đường dẫn.

6. Checklist lựa chọn

• Cần một tên khác cho cùng file trong cùng filesystem: xem xét hard link.
• Cần tham chiếu bằng đường dẫn hoặc trỏ tới thư mục: xem xét symlink.
• Cần bản sao độc lập: dùng cơ chế sao chép hoặc backup phù hợp, không dùng link thay thế.
• Kiểm tra filesystem cùng với inode, không so inode giữa hai filesystem.
• Thử hành vi lưu, thay thế và đồng bộ bằng đúng ứng dụng sẽ vận hành.

Hiểu liên kết là hiểu tên file đang dẫn tới đâu và ai quyết định cách truy cập. Quan sát trước, thử trong phạm vi nhỏ và tránh coi liên kết là bản sao sẽ giúp giảm nhiều lỗi thao tác filesystem.