Bugzilla – Bug 325212
[PATCH][Win32] PageFile does not exist for Mono
Last modified: 2008-01-26 14:43:21 UTC
---- Reported by gert.driesen@pandora.be 2007-08-23 07:27:34 MST ---- When using Mono, Directory.GetFiles returned an entry for the Windows pagefile but when using FileInfo to obtain information on the pagefile it reports that it does not exist. This prevents the (Open/Save)FileDialog from listing entries of the root directory of a volume containing a pagefile. To reproduce, compile and run the following code snippet on Windows: using System; using System.IO; class Program { static void Main () { FileInfo fi = new FileInfo (@"c:\pagefile.sys"); Console.WriteLine (fi.Exists); Console.WriteLine (fi.Attributes); Console.WriteLine (fi.FullName); Console.WriteLine (fi.Name); Console.WriteLine (fi.Length); Console.WriteLine (fi.LastAccessTime); } } Expected result: The following or similar output is written to the console: True Hidden, System, Archive c:\pagefile.sys pagefile.sys 1610612736 23/08/2007 10:56:22 Actual result: False 0 c:\pagefile.sys pagefile.sys Unhandled Exception: System.IO.FileNotFoundException: Could not find file "c:\pa gefile.sys". File name: "c:\pagefile.sys" at System.IO.FileInfo.get_Length () [0x00000] at (wrapper remoting-invoke-with-check) System.IO.FileInfo:get_Length () at Program.Main () [0x00000] ---- Additional Comments From robertj@gmx.net 2007-08-25 09:24:10 MST ---- This is a known "issue" on NT: GetFileAttributesEx() (used by MonoIO.GetFileStat()) demands read access for the queried object. A reliable way to do that is FindFirstFile(), which returns the same infos like GetFileAttributesEx(), but never fails, if the file exists. ---- Additional Comments From robertj@gmx.net 2007-08-25 09:26:59 MST ---- Forgot to mention that GetLastError () returns ERROR_SHARING_VIOLATION after GetFileAttributesEx ("c:/pagefile.sys", ...) ---- Additional Comments From robertj@gmx.net 2007-08-25 10:22:15 MST ---- Created an attachment (id=172536) bug-82545.diff ---- Additional Comments From robertj@gmx.net 2007-08-25 10:24:42 MST ---- The long an the short of it is still a patch ;-) ---- Additional Comments From robertj@gmx.net 2007-08-25 11:51:04 MST ---- Created an attachment (id=172537) bug-82545-update.diff - reworked patch Imported an attachment (id=172536) Imported an attachment (id=172537) Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>Windows XP SP2</cf_op_sys_details> Unknown operating system unknown. Setting to default OS "Other".
Dick, are you OK with this patch?
Is there any reason to have the ifdef WINDOWS parts? IMHO it's better to abstract the differences in io-layer and leave the callers in metadata/ and elsewhere to just use the same codepaths on all platforms.
As I understand, io-layer is unix only. This issue is about Windows, where GetFileAttributes is failing over files with restricted permissions. So I don't know where to abstract this.
Or do you mean to simulate Win32's behavior in io-layer and change all metadata & managed code to deal with a sometimes failing GetFileAttributes ()?
Yes, fix behaviour differences in io-layer if necessary and call that on linux and linux-like systems, and native w32 on windows.
Here's Robert's patch without the ifdefs. I'll commit this if this works for Gert and Robert doesn't object.
Created attachment 183679 [details] Reworked patch without ifdefs
Dick, under Unix this is redundant. If stat() fails with EACCES, we don't need to try readdir() because it will fail anyways. I'll try to find out if we can reduce the check to ERROR_SHARING_VIOLATION only.
ping?
Pong :) We can limit the test to ERROR_SHARING_VIOLATION: if (error != ERROR_SHARING_VIOLATION)) return res;
I forgot to ask: may I commit?
Do you mean a non-ifdef version? If so, go ahead. Otherwise we probably need to go through the patch again.
Yes, the non-ifdef with ERROR_SHARING_VIOLATION as the only check. I was not able to produce ACLs for which GetAttributes(Ex) returns ERROR_ACCESS_DENIED.
... for which GetAttributes(Ex) returns ERROR_ACCESS_DENIED but FindFirstFile would succeed. That is.
Sure, go ahead and commit. Thanks!
Fixed in SVN.