File.Exists and FileInfo.Exists fail to recognise existence of file


  • I'm having problems in accessing files that are newly created in a SharePoint location. I'm mapping a drive to a SharePoint share, and using the path as expressed through that mapped drive letter.

    However, when I try to work with a file that is created within that path, .NET's file system classes fail to recognise the file.

    Some observations:

    1. FileSystemWatcher seems unable to respond properly to file changes within the path, and won't recognise that the file has been created.

    2. File.Exists and FileInfo.Exists return FALSE for a file that exists.

    3. Windows Explorer doesn't list the file when it's created. Pressing F5 will list the file. From then, .NET's .Exists method seems to work.

    4. Directory.GetFiles and DirectoryInfo.GetFiles will list the file. However, the corresponding FileInfo object returned by DirectoryInfo.GetFiles doesn't return properties such as length and date stamps correctly, and FileInfo.Exists still returns FALSE.

    5. DoEvents has no effect.

    Any thoughts would be appreciated.

    (And does anyone know the mechanism behind Windows Explorer's F5?)

    Friday, June 30, 2006 1:39 PM

All replies

  • Are you using PortalServer or just Services?

    I'm thinking that the problem lies in the fact that the "shared folder" isn't real.  Typically, files that are uploaded to a SharePoint Library are actually stored in SQL server.  The shared folder may just be a virtual view of what is in SQL.  Now, I'm not 100% sure this is true - it would take a little research.

    I'm also thinking that there is a SharePoint SDK that will let you hook the actual sharepoint services for automation of spaces.  By referencing and querying SharePoint objects you should be able to get accurate Library information.

    Friday, June 30, 2006 3:36 PM
  • Thanks for your comments.

    I'm using Services currently, but would be looking to test on Portal Server too.

    Your comments regarding the shared folder make sense. However, Windows can eventually recognise these files through the mapped drive path. I've found that by initialising a FileInfo object based on the path and file name of a newly created file, and then calling the Refresh method of the FileInfo object, I can access other FileInfo properties and methods as I would expect. The Refresh method does need to be called several times, though.

    We have thought (briefly) about using SharePoint objects, but have the following reservations:

    1. The document store may not be a SharePoint location, so we would prefer to query file/folder objects through common  techniques.

    2. Would SharePoint processing be server-side only?

    However, we may need to pursue this further.

    Saturday, July 01, 2006 11:10 PM
  • Re. FileInfo.Refresh

    This only seems to work when interrupting the program execution when in the IDE, e.g. using break points, stepping through. When executing the program without interruption, I can call FileInfo.Refresh as many as 100,000 times, and still the system will fail to recognise the existence of the file.

    Monday, July 03, 2006 10:04 AM
  • Re. FileInfo.Refresh (again)

    It seems to take about 630,000 calls to FileInfo.Refresh (approx. 53 seconds) before the file is recognised.

    Does anyone have any ideas on how to prompt the system into responding a bit quicker?


    Monday, July 03, 2006 10:35 AM
  • If you want to test the delay method, put your application's thread to sleep for a while:

    'Call Refresh
    System.Threading.Thread.Sleep(53000) 'wait for 53 seconds
    'Call Refresh

    You could still use the SharePoint objects and check for the existence of a library; if it is not found, then use normal System.IO objects.

    Any manipulation of a Library is going to be done server-side.

    As far as I know, the only way to speed up the local pc "seeing" the Document Library via a folder is to beef up the SharePoint server, ensure that all domain communication is free and smooth, and possibly increase network throughput.
    -EDIT- Also, the SQL server may need more horsepower and the pipe between the SQL server and the SharePoint server may not be big enough.  If you're running SQL Express and not Server then that may be the biggest issue. -END EDIT-

    This sounds like the same issues seen when attempting to access a DFS share via a UNC path from a program...

    Wednesday, July 05, 2006 3:12 PM