2013-08-16 53 views
20
System.IO.File.Exists(string path) 

trả về luôn luôn sai, ngay cả khi tệp tồn tại trên đường dẫn được chỉ định. Điều gì có thể là giải pháp khả thi?Tại sao System.IO.File.Exists (đường dẫn chuỗi) trả về false?

+5

* Nếu người gọi không có đủ quyền để đọc các tập tin chỉ định, không có ngoại lệ được ném ra và phương pháp trả về false không phụ thuộc vào sự tồn tại của con đường.* – V4Vendetta

+1

Có thể là do không đủ tư cách? Hãy thử chạy exe với tư cách quản trị viên. –

Trả lời

36

Nó cũng có thể là vấn đề về quyền. Từ số documentation:

Phương thức hiện tại trả về false nếu xảy ra lỗi khi xác định xem tệp đã chỉ định có tồn tại hay không. Điều này có thể xảy ra trong các tình huống làm tăng các ngoại lệ như truyền tên tệp với các ký tự không hợp lệ hoặc quá nhiều ký tự, đĩa bị lỗi hoặc bị thiếu hoặc nếu người gọi không có quyền đọc tệp.

Một cách để xem điều gì đang xảy ra là cố gắng đọc tệp (ví dụ: File.OpenRead). Tôi sẽ ngạc nhiên nếu điều đó thành công - nhưng nếu không thành công, ngoại lệ sẽ cung cấp cho bạn thêm thông tin.

+5

File.OpenRead đã làm việc cho tôi. nhưng File.Exists vẫn trả về false .. Tôi bị bối rối ... – Vlad

+0

@Vlad Yep, cùng ở đây. Tôi đã sử dụng bối cảnh mạo danh - tôi không biết liệu có liên quan gì đến nó hay không. Nhưng nếu nó có thể đọc nó - tôi thậm chí còn tạo ra một 'Stream s = File.OpenRead (đường dẫn);' và sử dụng một hàm để đọc trong các byte thành một mảng byte! - Tôi không biết tại sao nó không thể trả về 'true' cho' bool fileExists = File.Exists (path); '; Trên thực tế, có thể "quá nhiều ký tự" trong đường dẫn tệp có thể là những gì nó đã xảy ra đối với tôi. – vapcguy

3

Cách tôi nhận được thông tin này đang sử dụng Server.MapPath(fileName) vì nó tiếp tục cố gắng tìm tệp ở một nơi khác.

System.IO.File.Exists(Server.MapPath(string path)) 
+0

Có ai biết nếu đây là sự khác biệt giữa các phiên bản .NET hay gì đó không? Điều này được sử dụng để làm việc trước khi một ứng dụng được nâng cấp lên .NET 4.5. Đột nhiên, đó là một vấn đề. –

+0

Điều này sẽ không hoạt động trong các ứng dụng Windows, thật không may là – MC9000

0

Tôi cũng đã tự mình trải nghiệm điều này. Trong trường hợp của tôi, tôi đã xóa tập tin và tạo lại nó. Trong quá trình xóa tệp, tôi đã quên thêm vào WaitForExit() trước khi sử dụng File.Exists sau này trên

-3

Sử dụng \\ thay vì @. Ví dụ:

@ "C: \ file.txt" -> "C: \\ file.txt"

5

kết thúc tập tin Ẩn trong cửa sổ đôi khi có thể gây nhầm lẫn: bạn BIẾT tập tin của bạn được đặt tên tập tin. txt khi nó thực sự được đặt tên file.txt.txt vì 4 ký tự cuối cùng đã bị hệ điều hành ẩn.

+0

Xóa đuôi tệp trong tên tệp đã hoạt động cho tôi .. thankuu :) – Deepzz

+0

* Nhíp cầu mũi - ahhhhhhhhhhhh – rory

1

trong trường hợp của tôi, một "dấu gạch ngang" khác trong tên tệp gây ra sự cố.

var f1 = "4-37R.pdf"; 
var f2 = "4‐37R.pdf"; 
var r = f1==f2?"same":"diff"; 
Console.Write(r); //diff 

quay ra

var c1 = '-'; 
var c2 = '‐'; 
Console.WriteLine((int)c1); //45 
Console.WriteLine((int)c2); //8208 

sử dụng cùng một '-' sửa chữa vấn đề này.

1

Điều này khiến tôi bối rối trong khi tôi đang gỡ lỗi dịch vụ cục bộ, tôi đang chạy File.Exists ("U: \ dir1") đối với vị trí máy chủ được ánh xạ trên máy trạm của tôi dưới dạng (U :). Tôi đã thay thế U: \ dir1 thành "\\ serverPath \ dir1" và File.Exists rồi trả về true.

4

Một khả năng không được đề cập trong bất kỳ câu trả lời nào ở đây là 'Chuyển hướng hệ thống tệp' trên Windows 8.1 trở đi.

Ví dụ: nếu chương trình của bạn là ứng dụng 32 bit và bạn đang chạy trên Windows 64 bit thì nỗ lực truy cập% windir% \ System32 sẽ được chuyển hướng đến% windir% \ SysWOW64. Và nếu tệp bạn đang cố truy cập không tồn tại trong% windir% \ SysWOW64 thì System.IO.File.Exists (đường dẫn chuỗi) sẽ trả về Sai.

Link to a nice article explaining this behavior

+0

Cảm ơn bạn SO MUCH !!!!!!!!!!! Tôi đã bị mắc kẹt trên này cho như thế, tôi không biết, ít nhất bốn giờ. –

Các vấn đề liên quan