FindFirst : with network files it fails

[gioma 19]

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.

[PeterBelow 239]

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.

[gioma 19]

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. 

[DelphiUdIT 187]

For a long time I have always used the form "\\?\". It has some advantages (like bypass MAX_PATH limits and the name parsing).

See here: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces

 

Bye

Edited November 27 by DelphiUdIT

[dwrbudr 8]

Adding \\?\ does not automatically bypas MAX_PATH, unless some other extra steps are being made, e.g. modifing the manifest file and a setting in the registry.

 

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

 

 

[Remy Lebeau 1429]

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 December 6 by Remy Lebeau