Thao tác được yêu cầu không thể được thực hiện trên một tệp có phần ánh xạ người dùng mở

Bất cứ khi nào tôi cố gắng sao chép 4 tệp vào thư mục bin của mình, sau khi dừng dịch vụ chính, tôi gặp lỗi với một tệp (TexteDll). Lỗi là:

Cannot copy TexteDll: The requested operation cannot be performed on a file 
with a user-mapped section open

Nó có thể là do một số hệ thống khóa. Hoặc có lẽ một quá trình khác đang sử dụng DLL này. Khi tôi googled, tôi thấy rằng việc khởi động lại hệ thống có thể giải quyết điều này.

Bất cứ ai có thể đề nghị một nguyên nhân hoặc giải pháp cho điều này? Tôi đã kiểm tra các thuộc tính của TexteDll (chung, phiên bản, bảo mật, v.v.). Mọi thứ xuất hiện bình thường.

Trong trường hợp của tôi, đó là Explorer đã khóa DLL được biên dịch trong thư mục Debug ... Lạ nhỉ, phải không?

Tôi phát hiện ra bằng cách sử dụng một công cụ gọi là Unlocker.

Phải xóa bằng Unlocker, ngay cả khi nó nói rằng không có khóa trên tệp và tôi không thể xóa thư mục cho đến khi tôi không xóa tệp đó ...

Sau đó nó biên soạn.

BIÊN TẬP:

Tôi đã tìm ra lý do tại sao trong trường hợp của tôi điều này đã xảy ra. Tôi đã mở DLL trong trình soạn thảo văn bản trong Visual Studio ...

• Đôi khi, khi bạn nhấp đúp vào cảnh báo về phiên bản lắp ráp được tham chiếu không khớp giữa hai hoặc nhiều dự án, bạn quên đóng cửa sổ xem lắp ráp và nó vẫn ở đó giữa các tab khác ... vì vậy bạn kết thúc việc lắp ráp bị khóa bởi chính VS và tôi đã mất khá nhiều thời gian để tìm ra điều đó :)

  Hãy cẩn thận với sức mạnh mà VS cung cấp;)

• Một kịch bản giả khác. Đôi khi chỉ cần xóa toàn bộ thư mục obj hoặc chỉ tập tin được cảnh báo là khóa bị khóa giúp khắc phục lỗi này.

đóng tất cả các tài liệu về VS và cố gắng xây dựng lại. Nếu nó không hoạt động, hãy khởi động lại VS. Vấn đề này liên quan đến khóa các tập tin DLL.

Đóng visual studio, xóa bin, thư mục phát hành gỡ lỗi và bắt đầu lại dự án studio visual. đã khắc phục vấn đề của tôi

Tôi gặp vấn đề tương tự và trong trường hợp của tôi, có vẻ như tệp đầu ra hiện tại đã bị khóa bởi ứng dụng khác.

Bạn có thể kiểm tra ứng dụng nào đang khóa tệp đầu ra của mình bằng OpenedFilesView: http://www.nirsoft.net/utils/opened_files_view.html

Tôi là nhà phát triển và không thích các ứng dụng được đưa vào Đăng ký như Unlocker. Tôi đã sử dụng SysIternals Process Explorer để xử lý khóa dll của tôi Find > Find Handle or Dll [Ctrl-F]và giết tiến trình.

Những người khác đã xác định rằng lỗi này là do một ứng dụng khác có khóa trên tệp. Chỉ muốn chỉ ra rằng git diffkhóa các tập tin là tốt cho đến khi bạn thoát khỏi nó. Đó là những gì gây ra điều này trong trường hợp của tôi.

Tôi gặp vấn đề tương tự. Làm thế nào tôi giải quyết nó là:

1. Mở "Trình quản lý tác vụ"
2. Kết thúc tác vụ "Explorer.exe"
3. Nhấp vào "Tệp" -> Tạo tác vụ mới - Nhập vào "explorer.exe" -> OK
4. Làm sạch dự án của tôi và nó hoạt động

Bạn đang chạy bất kỳ phần mềm chống vi-rút. Có thể phần mềm AV (hoặc một số phần mềm khác) đang đọc tệp bằng API ánh xạ tệp gây ra sự cố.

Trong trường hợp của tôi, tôi đã phải giết một MSBuild.exequy trình treo đang khóa tệp (nó đã ở đó ngay cả sau khi tôi đóng Visual Studio).

Xóa thư mục obj và xây dựng lại làm việc cho tôi

Tôi đã từng gặp vấn đề tương tự. Khởi động lại không làm việc cho tôi. Có một quy trình gọi là VBSCompiler đang chạy trong trình quản lý tác vụ. Tôi đã phải kết thúc quá trình để sửa lỗi này.

Không có giải pháp nào được đăng ở đây làm việc cho tôi. Đó là devenv.exe (Visual Studio) đang khóa tệp, nhưng nếu tôi khởi động lại, nó sẽ khóa lại.

Thật kỳ lạ, Windows sẽ không cho phép tôi xóa các tệp (vào Thùng rác), nhưng Shift + Xóa (xóa vĩnh viễn) đã hoạt động.

Đóng Visual Studio và chạy nó với tư cách quản trị viên. Nó đã khắc phục vấn đề của tôi.

Giải pháp cho tôi là loại bỏ tất cả các phiên bản của VS và tiêu diệt mọi quá trình devenv.exe treo.

Giải pháp cho tôi là khởi động lại máy tính.

Andrew Cuthbert đã chỉ ra vào năm 2016 rằng git diff cũng khóa các tập tin cho đến khi bạn thoát khỏi nó.

Điều đó sẽ không xảy ra với Git 2.23 (quý 3 năm 2019)

Xem cam kết 3aef54e (ngày 11 tháng 7 năm 2019) của tác giả Julian Schindelin ( dscho) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết d9beb46 , ngày 25 tháng 7 năm 2019)}

diff: munmap()nội dung tập tin trước khi chạy diff khác

Khi chạy một khác biệt bên ngoài từ, giả sử, a diff tool, có thể an toàn khi giả định rằng chúng tôi muốn viết các tệp trong câu hỏi.
Trên Windows, điều đó có nghĩa là không thể có bất kỳ quy trình nào khác đang xử lý mở đối với các tệp đã nói hoặc thậm chí chỉ là một vùng được ánh xạ.

Vì vậy, hãy đảm bảo rằng git diffchính nó không giữ bất kỳ xử lý mở nào đối với các tệp được đề cập.

Trên thực tế, chúng tôi sẽ chỉ phát hành cặp tệp ngay lập tức, vì khác biệt bên ngoài sử dụng các tệp chúng tôi vừa viết, vì vậy chúng tôi không cần phải giữ nội dung tệp trong bộ nhớ nữa.

Điều này sửa git-for-windows # 1315

Tôi đã thấy những lỗi này khi xây dựng các ứng dụng Dot Net với Ant.

Trong trường hợp của tôi, đó là phần mềm sao lưu công ty của chúng tôi, Symantec DLO Agent. Dừng nó và loại trừ thư mục trong phần mềm chống vi-rút của tôi và đóng Visual Studio dường như hoạt động.

trong trường hợp của tôi đã xóa thư mục obj trong dự án root và xây dựng lại dự án đã giải quyết vấn đề của tôi !!!

Tôi đã gặp lỗi này và hóa ra vấn đề là FxCop đang chạy chống lại dự án của tôi. Tôi đã đóng FxCop và sau đó tôi có thể biên dịch lại.

Nếu đó là một ứng dụng web xóa các tệp trong thư mục Tệp ASP.NET tạm thời có thể là một giải pháp.

Nếu bạn đang sử dụng các trình định dạng như AQ Time, chúng cũng có thể khóa tệp. Giải pháp trong trường hợp này là khởi động lại trình lược tả hoặc đơn giản là dỡ / tải cụm được đề cập từ trình lược tả. Đối với AQ Time tôi nhận thấy rằng nó sẽ phát hành tệp sau một thời gian, nhưng tôi không thể biết thời gian chờ đó là bao nhiêu. Có vẻ là ngẫu nhiên

Tôi cũng có lỗi tương tự ngày hôm nay. Tôi đã giải quyết vấn đề này bằng cách xây dựng lại dự án.

Tôi đã gặp lỗi này do 'thêm' so với tệp đang nghi vấn đang chạy trong bảng điều khiển khác. Giáo sư.

Không có điều nào ở trên giải quyết được vấn đề này.

Ai đó đã có một dự án trong giải pháp của tôi được thiết lập để sử dụng CPU x64 trong cấu hình xây dựng. Thay đổi nó thành Bất kỳ CPU nào khiến bản dựng sử dụng một thư mục mới. Tôi vẫn không biết quá trình nào đã có (có) khóa trên tệp đó.

Tôi đã có vấn đề tương tự . Tôi đã xóa dll khỏi thư mục tạm thời, xóa quyền truy cập chỉ đọc và khởi động lại máy và làm cho nó hoạt động.

Trong trường hợp của tôi, tôi chỉ cần đóng tất cả các thể hiện và sao chép thư mục ứng dụng gốc của mình và dán nó vào vị trí khác nhau sau đó mở giải pháp trong VS nó hoạt động ....

Vấn đề của tôi cũng đã được giải quyết bằng cách chọn lọc thông qua Process Explorer. Tuy nhiên, quá trình tôi phải giết là MySQL Notifier.exe vẫn đang chạy sau khi đóng tất cả các ứng dụng VS và SQL.