Khóa tệp thực thi: Windows thì có, Linux thì không. Tại sao?

Tôi nhận thấy khi tệp được thực thi trên Windows (.exe hoặc .dll), tệp đó bị khóa và không thể xóa, di chuyển hoặc sửa đổi.

Mặt khác, Linux không khóa các tệp đang thực thi và bạn có thể xóa, di chuyển hoặc sửa đổi chúng.

Tại sao Windows khóa trong khi Linux thì không? Có một lợi thế để khóa?

Linux có cơ chế đếm tham chiếu, vì vậy bạn có thể xóa tệp trong khi tệp đang thực thi và nó sẽ tiếp tục tồn tại miễn là một số quy trình (Đã mở trước đó) có một xử lý mở cho nó. Mục nhập thư mục cho tệp sẽ bị xóa khi bạn xóa nó, vì vậy nó không thể mở được nữa, nhưng các quy trình đã sử dụng tệp này vẫn có thể sử dụng nó. Khi tất cả các quy trình sử dụng tệp này kết thúc, tệp sẽ tự động bị xóa.

Windows không có khả năng này, vì vậy nó buộc phải khóa tệp cho đến khi tất cả các quá trình thực thi từ nó kết thúc.

Tôi tin rằng hành vi Linux là thích hợp hơn. Có thể có một số lý do kiến ​​trúc sâu xa, nhưng lý do chính (và đơn giản) mà tôi thấy thuyết phục nhất là trong Windows, đôi khi bạn không thể xóa một tệp, bạn không biết tại sao và tất cả những gì bạn biết là một số quy trình đang giữ nó trong sử dụng. Trong Linux, điều đó không bao giờ xảy ra.

Theo như tôi biết, Linux không thực thi khóa khi họ đang chạy - tuy nhiên, nó khóa inode . Điều này có nghĩa là bạn có thể xóa "tệp" nhưng inode vẫn còn trên hệ thống tệp, không bị ảnh hưởng và tất cả những gì bạn thực sự xóa là một liên kết.

Các chương trình Unix luôn sử dụng cách suy nghĩ này về hệ thống tệp, tạo một tệp tạm thời, mở nó, xóa tên. Tệp của bạn vẫn tồn tại nhưng tên được giải phóng cho người khác sử dụng và không ai khác có thể nhìn thấy nó.

Linux không khóa các tệp. Nếu bạn cố gắng ghi đè lên tệp đang thực thi, bạn sẽ nhận được "ETXTBUSY" (Tệp văn bản bận). Tuy nhiên, bạn có thể xóa tệp và hạt nhân sẽ xóa tệp khi tham chiếu cuối cùng đến nó bị xóa. (Nếu máy không tắt hoàn toàn, các tệp này là nguyên nhân gây ra thông báo "Đã xóa inode không có thời gian d-time" khi hệ thống tệp được kiểm tra, chúng chưa bị xóa hoàn toàn, vì một quá trình đang chạy có tham chiếu đến chúng, và bây giờ họ đang có.)

Điều này có một số ưu điểm chính, bạn có thể nâng cấp một quy trình đang chạy, bằng cách xóa tệp thực thi, thay thế nó, sau đó khởi động lại quy trình. Ngay cả init cũng có thể được nâng cấp như thế này, thay thế tệp thực thi và gửi tín hiệu cho nó và nó sẽ tự thực thi lại () mà không yêu cầu khởi động lại. (Thường được thực hiện tự động bởi hệ thống quản lý gói của bạn như một phần của quá trình nâng cấp)

Trong cửa sổ, việc thay thế một tệp đang được sử dụng dường như là một rắc rối lớn, thường yêu cầu khởi động lại để đảm bảo không có quy trình nào đang chạy.

Có thể có một số vấn đề, chẳng hạn như nếu bạn có một tệp nhật ký cực kỳ lớn và bạn xóa nó, nhưng quên nói với quá trình đang ghi nhật ký vào tệp đó để mở lại tệp, nó sẽ giữ tham chiếu và bạn sẽ tự hỏi tại sao đĩa của bạn đột nhiên không nhận được nhiều dung lượng trống hơn.

Bạn cũng có thể sử dụng thủ thuật này trong linux cho các tệp tạm thời. mở tệp, xóa nó, sau đó tiếp tục sử dụng tệp. Khi quá trình của bạn thoát (vì bất kỳ lý do gì - ngay cả khi mất điện), tệp sẽ bị xóa.

Các chương trình như lsof và fuser (hoặc chỉ cần dò tìm trong / proc // fd) có thể cho bạn biết quy trình nào có các tệp đang mở mà không còn tên.

Tôi nghĩ linux / unix không sử dụng cùng một cơ chế khóa vì chúng được xây dựng từ đầu như một hệ thống nhiều người dùng - điều này sẽ mong đợi khả năng nhiều người dùng sử dụng cùng một tệp, thậm chí có thể cho các mục đích khác nhau.

Có một lợi thế để khóa? Chà, nó có thể làm giảm số lượng con trỏ mà Hệ điều hành sẽ phải quản lý, nhưng hiện tại, số tiền tiết kiệm được là không đáng kể. Ưu điểm lớn nhất mà tôi có thể nghĩ đến để khóa là điều này: bạn tiết kiệm được một số sự mơ hồ có thể xem của người dùng. Nếu người dùng a đang chạy một tệp nhị phân và người dùng b xóa nó, thì tệp thực sự phải tồn tại cho đến khi quá trình của người dùng A hoàn tất. Tuy nhiên, nếu Người dùng B hoặc bất kỳ người dùng nào khác tìm nó trên hệ thống tệp, họ sẽ không thể tìm thấy nó - nhưng nó sẽ tiếp tục chiếm dung lượng. Không thực sự là một mối quan tâm lớn đối với tôi.

Tôi nghĩ phần lớn là câu hỏi về khả năng tương thích ngược với hệ thống tệp của window.

Tôi nghĩ bạn quá tuyệt đối về Windows. Thông thường, nó không phân bổ không gian hoán đổi cho phần mã của tệp thực thi. Thay vào đó, nó giữ một khóa trên các tệp tin & DLL. Nếu các trang mã bị loại bỏ là cần thiết một lần nữa, chúng chỉ cần tải lại. Nhưng với / SWAPRUN, các trang này được giữ ở dạng hoán đổi. Điều này được sử dụng cho các tệp thực thi trên CD hoặc ổ đĩa mạng. Do đó, các cửa sổ không cần phải khóa các tệp này.

Đối với .NET, hãy xem Shadow Copy .

Nếu mã được thực thi trong một tệp có bị khóa hay không là do thiết kế quyết định và MS chỉ đơn giản là quyết định khóa, bởi vì nó có lợi thế rõ ràng trong thực tế: Bằng cách đó, bạn không cần biết mã trong phiên bản nào được ứng dụng nào sử dụng. Đây là một vấn đề lớn với hành vi mặc định của Linux, mà hầu hết mọi người đều bỏ qua. Nếu các lib trên toàn hệ thống được thay thế, bạn không thể dễ dàng biết ứng dụng nào sử dụng mã của các lib như vậy, hầu hết những lần tốt nhất bạn có thể nhận được là trình quản lý gói biết một số người dùng của các lib đó và khởi động lại chúng. Nhưng điều đó chỉ hoạt động đối với những thứ chung chung và biết rõ như có thể là Postgres và các lib của nó hoặc tương tự. Các tình huống thú vị hơn là nếu bạn phát triển ứng dụng của riêng mình chống lại một số lib của bên thứ 3 và những ứng dụng đó bị thay thế, bởi vì hầu hết các trường hợp trình quản lý gói chỉ đơn giản là không biết ứng dụng của bạn. Và đó ' Không chỉ là vấn đề của mã C gốc hoặc như vậy, nó có thể xảy ra với hầu hết mọi thứ: Chỉ cần sử dụng httpd với mod_perl và một số Perl libs được cài đặt bằng trình quản lý gói và để trình quản lý gói cập nhật những Perl lib đó vì bất kỳ lý do gì. Nó sẽ không khởi động lại httpd của bạn, đơn giản vì nó không biết các phần phụ thuộc. Có rất nhiều ví dụ như ví dụ này, đơn giản vì bất kỳ tệp nào cũng có thể chứa mã được sử dụng trong bộ nhớ trong bất kỳ thời gian chạy nào, hãy nghĩ đến Java, Python và tất cả những thứ như vậy.

Vì vậy, có lý do chính đáng để có ý kiến ​​rằng khóa tệp theo mặc định có thể là một lựa chọn tốt. Tuy nhiên, bạn không cần phải đồng ý với những lý do đó.

Vậy MS đã làm gì? Họ chỉ đơn giản là tạo ra một API để cho ứng dụng gọi điện có cơ hội quyết định xem tệp có nên bị khóa hay không, nhưng họ quyết định rằng giá trị mặc định của API này là cung cấp một khóa độc quyền cho ứng dụng gọi đầu tiên. Hãy xem API xung quanh CreateFile và dwShareModeđối số của nó . Đó là lý do tại sao bạn không thể xóa tệp đang được sử dụng bởi một số ứng dụng, nó chỉ đơn giản là không quan tâm đến trường hợp sử dụng của bạn, sử dụng các giá trị mặc định và do đó, Windows đã khóa riêng một tệp.

Vui lòng không tin vào những người nói với bạn điều gì đó về việc Windows không sử dụng số lần tham chiếu trên HANDLEs hoặc không hỗ trợ Liên kết cứng hoặc tương tự, điều đó hoàn toàn sai. Hầu hết mọi API sử dụng HANDLEs đều ghi lại hành vi của nó liên quan đến việc đếm tham chiếu và bạn có thể dễ dàng đọc trong hầu hết các bài viết về NTFS mà nó trong chứng thư có hỗ trợ Liên kết cứng và luôn làm như vậy. Kể từ khi Windows Vista nó cũng hỗ trợ Symlinks và Hỗ trợ cho Hardlinks đã được cải thiện bằng cách cung cấp các API để đọc tất cả các API đó cho một tệp nhất định, v.v.

Ngoài ra, bạn có thể chỉ muốn xem các cấu trúc được sử dụng để mô tả tệp trong Ext4 so với cấu trúc của NTFS , chúng có rất nhiều điểm chung. Cả hai đều hoạt động với khái niệm phạm vi, phân tách dữ liệu khỏi các thuộc tính như tên tệp và inodes gần như chỉ là một tên khác của một khái niệm cũ hơn, nhưng tương tự về điều đó. Ngay cả Wikipedia cũng liệt kê cả hai hệ thống tệp trong bài viết của mình .

Thực sự có rất nhiều FUD xung quanh việc khóa tệp trong Windows so với các hệ điều hành khác trên mạng, giống như về chống phân mảnh. Một số FUD này có thể được loại trừ bằng cách đọc một chút trên Wikipedia .

Các biến thể NT có

mở tập tin

lệnh này sẽ hiển thị các quy trình có xử lý tệp nào. Tuy nhiên, nó yêu cầu bật cờ toàn cầu hệ thống 'danh sách đối tượng duy trì'

openfiles / local /?

cho bạn biết cách thực hiện điều này và cũng như chịu một khoản phạt về hiệu suất khi làm như vậy.

Các tệp thực thi được ánh xạ dần vào bộ nhớ khi chạy. Điều đó có nghĩa là các phần của tệp thực thi được tải khi cần thiết. Nếu tệp bị hoán đổi trước khi tất cả các phần được ánh xạ, nó có thể gây ra sự mất ổn định lớn.