'ln -s` trong một kịch bản đóng vai trò như' cp`

Question

Vấn đề

Tôi có kịch bản bash này:

ACTIVE_DB=$(grep -P "^[ \t]*db.active" config.properties | cut -d= -f2 | tr -s " ") 
echo $ACTIVE_DB 
if [ "$ACTIVE_DB" = "A" ] 
then 
    ln -sf config-b.properties config.properties 
else 
    ln -sf config-a.properties config.properties 
fi 

config-a.properties

db.active = A 

config-b. thuộc tính

db.active = B 

Khi tôi chạy tập lệnh, một đồng py (= cp) được thực hiện và config.properties thường không phải là một liên kết tượng trưng (cũng không phải là liên kết thực tế cho vấn đề đó) mà là một tệp hoàn toàn mới có cùng nội dung như config-a.properties hoặc config-b.properties.

$ ls -li 
53 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-a.properties 
54 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-b.properties 
56 -rw-r--r-- 1 ogregoir ogregoir  582 Oct 2 11:28 config.properties 

Khi tôi chạy này trong lời nhắc bằng tay từng dòng, tôi không có rắc rối và một liên kết tượng trưng thực sự là luôn luôn tạo ra và config.properties điểm về phía config-a.properties hoặc config-b.properties.

$ ls -li 
53 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-a.properties 
54 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-b.properties 
55 lrwxrwxrwx 1 ogregoir ogregoir  20 Oct 2 11:41 config.properties -> config-b.properties 

Ghi chú

• Không có tập tin đang mở bất cứ nơi nào khác (Tôi là người dùng tích cực duy nhất và các ứng dụng bằng cách sử dụng cấu hình không hoạt động).
• Đôi khi ln -sf hoạt động bình thường, nhưng quy tắc thông thường là nó tạo bản in ra giấy.
• Tập lệnh được chạy từ một thư mục khác, nhưng cd s vào thư mục nơi tệp config*.properties được đặt trước khi thực hiện các tác vụ tại đây.
• Tập lệnh dài hơn nhiều, nhưng đây là ví dụ ngắn nhất tạo lại lỗi.
• bash phiên bản là 4.1.2 (địa phương, vì vậy tôi không quan tâm đến shellshock).
• ln phiên bản là 8.4.
• Hệ điều hành: Red Hat Enterprise Máy chủ Linux phát hành 6.5 (Santiago).
• Hệ thống tệp được sử dụng cho thư mục đó: ext4.

Câu hỏi

• Tại sao không kịch bản của tôi luôn tạo ra một liên kết tượng trưng nhưng làm cho một bản sao cứng?
• Làm cách nào để bắt buộc liên kết tượng trưng ở đây?

Answer 1

Tôi nghi ngờ bạn có một số tập lệnh hoặc mã khác đang ghi đè lên các liên kết tượng trưng. Ví dụ: sed -i sẽ chuyển các liên kết rác. Có rất nhiều lệnh và tiện ích sửa đổi tệp bằng cách tạo bản sao, sửa đổi bản sao và sau đó di chuyển bản sao lên trên bản gốc, phá hủy liên kết gốc ban đầu.

Answer 2

Câu trả lời duy nhất có thể cho câu hỏi (như được hỏi): tại sao ln hoạt động như cp là: Có thể không.

Câu trả lời duy nhất có thể có là: những gì bạn trình bày cho chúng tôi không chính xác những gì đang được thực thi, hoặc có các kịch bản khác chạy thay đổi câu trả lời.

Một số lựa chọn thay thế có thể:
1.- Lệnh ln thực sự đang thực hiện liên kết cứng.Danh sách i-nút (ls -li) xác nhận rằng các số i-nút là khác nhau. Vì vậy, không, đó không phải là lý do.

2.- Có bí danh hoặc chức năng cho ln không?
Thật dễ dàng để kiểm tra. Chỉ cần phát hành type -a ln bên trong Bash. Kết quả sẽ hiển thị bash là gì để giải thích ln. Nếu nó CHỈ là tập tin /bin/ln, thì nó là chính xác.
Bạn xác nhận rằng không có bí danh hoặc chức năng nào có liên quan.

3.- Khi "tập lệnh được chạy từ thư mục khác". Điểm ở đây là: Có tệp nào khác ở bất kỳ đâu trong hệ thống tệp có cùng số i-nút không (nếu ln thực sự đang tạo liên kết cứng). Sự tồn tại của một số tập tin khác với inode tương tự có thể được xác nhận với (sử dụng số inode 53,54,56 từ danh sách của bạn):

find/-follow -inum <your inum> 

4.- Tôi hy vọng rằng bạn đang thực sự nhận thức được rằng config-b.properties không thực sự tồn tại (dưới dạng tệp). Chỉnh sửa tệp như vậy có thể làm hỏng liên kết.

Tập lệnh thực tế có được thực hiện cũng thay đổi/cập nhật nội dung tệp không?

Note01: Lưu ý rằng các trick K không giải quyết việc khai thác chỉ trong một cuộc gọi bên ngoài: http://www.charlestonsw.com/perl-regular-expression-k-trick/

ACTIVE_DB=$(grep -Po "^[ \t]*db.active[ ]+=[ ]+\K." config.properties) 

Nó đã được xác nhận rằng một sed -i-config-b.properties sau này trong kịch bản thực thi là nguồn gốc của các vấn đề.