Jump to content
gioma

FindFirst : with network files it fails

Recommended Posts

Hi,

I need to retrieve information about a file, to do so I use the FindFirst function.
The problem is when I use it with a network file it returns error 2: The system cannot find the file specified.

 


//FileName='\\SERVER-CODE\DelphiShared\Test.txt'
//FileName='\\192.168.0.100\DelphiShared\Test.txt'
procedure PrepareToTransferLocalFiles(FileName:string);
begin
  if FindFirst(FileName, faAnyFile, sr) = 0 then
  begin
  	//some code..
  else begin
     WriteLog('[PrepareToTransferLocalFiles] Open File ' + FileName + ' Err: '+intToStr(GetLastError)+' : '+SysErrorMessage(GetLastError)+')' );
   end;
   FindClose(sr);
   //some code..
end;

where am I going wrong?

 

PS
The program uses a browser component that uses network authentication when it needs to access protected folders.

Share this post


Link to post

You need file system level authentification to access files on the LAN via file system API functions, see WNetAddConnection3 if this is for Windows. For web folders you have to use something like ftp if the server supports it.

Share this post


Link to post
23 hours ago, PeterBelow said:

You need file system level authentification to access files on the LAN via file system API functions, see WNetAddConnection3 if this is for Windows. For web folders you have to use something like ftp if the server supports it.

thanks for the reply.
Yes, what you say is already done by the browser component, the problem is another, for network paths I always have to add the prefix "\\?\UNC\" otherwise it doesn't work. 

Share this post


Link to post
47 minutes ago, dwrbudr said:

Adding \\?\ does not automatically bypas MAX_PATH

Yes, it does. And has done so for a VERY VERY LONG time, long before the "manifest file and a setting in the registry" you refer to ever existed.

 

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

Quote

For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.

NTFS is such a file system, which has been supported since Windows 3.1, though long paths were not supported on it until Windows 95.  MAX_PATH is an artificial limitation of the Win32 API, not of the file system. The more commonly referred documention about this is:

 

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Quote

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformationfunction (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

 

The "manifest file and a setting in the registry" that you refer to simply allows an app to use such long paths without needing to use the "\\?\" prefix anymore.

Quote

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from many common Win32 file and directory functions. However, your app must opt-in to the new behavior.

 

Edited by Remy Lebeau

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×