Discussion:
FindFirst(File) mit url
(too old to reply)
Erwin Ahlers
2010-04-21 19:45:23 UTC
Permalink
Hallo,
ich suche auf einem externen Laufwerk mit FindFirst oder FindFirstFile
nach Dateien. Solange ich das Laufwerk gemappt habe, und somit über
einen Buchstaben ansprechbar ist, funktioniert alles sehr gut. Nun
kann ich das Laufwerk aber auch mit \\Server\Verzeichnis ansprechen.
Dafür muss es nicht gemappt sein. Nur funktioniert dann
FindFirst(File) nicht mehr. Er scheint einen Pfad nach <Buchstabe>:
\<Pfad> zu erwarten.
Hat jemand eine Idee, wie ich nach \\<Server>\<Pfad> suchen kann?

Gruß
Erwin
Erwin Ahlers
2010-04-22 08:19:21 UTC
Permalink
Sorry, I used the wrong Delphi group. It should have been the german
one.
Never mind the question is one sentence: how to use some find file
functions when I use an URL like file name, e.g. \\server\dir1\*.pas
The normal findFirst or findFirstFile don't accept this.

Erwin
Maarten Wiltink
2010-04-22 11:06:33 UTC
Permalink
Post by Erwin Ahlers
Sorry, I used the wrong Delphi group. It should have been the german
one.
This is an international group. That no longer means English-language
as it once did. Modern etiquette seems to be that you get to ask in
any language you want, the number of replies _will_ differ by language,
and if you tell people off for posting in a language you don't
understand, you will be told that xenophobia is no longer cool, but
speaking your languages is. (Or that may just be my personal position.)
Post by Erwin Ahlers
Never mind the question is one sentence: how to use some find file
functions when I use an URL like file name, e.g. \\server\dir1\*.pas
The normal findFirst or findFirstFile don't accept this.
Be careful what you call 'normal'. You may be up against subtle
differences between platform and RTL implementations. (Be careful also
what you call a URL. UNC paths aren't.)

According to MSDN, the WinAPI function FindFirstFile _does_ accept UNC
paths. It also mentions you should include a mask, which you do. So
Windows.FindFirstFile() should have worked. If it didn't, ask Windows
what went wrong. I forget how exactly, something like GetLastOSError.

In the RTL, there may be FindFirst and FindFirstFile functions in
System, SysUtils, FileUtils, DirUtils, and perhaps other places. They
may try to give extra information and in doing so, break things. Read
the source. Press F8 a lot.

Groetjes,
Maarten Wiltink
Jamie
2010-04-23 11:38:23 UTC
Permalink
Post by Erwin Ahlers
Sorry, I used the wrong Delphi group. It should have been the german
one.
Never mind the question is one sentence: how to use some find file
functions when I use an URL like file name, e.g. \\server\dir1\*.pas
The normal findFirst or findFirstFile don't accept this.
Erwin
You need to use the Wide version of FindFirstfile.

FindFirstFileW

Also, beware of translating C/C++ over to delphi when reading
data with in "xxxx". You must remember that C likes to use
control characters in the strings..
things like "\\" actually are "\"
etc//
Rob Kennedy
2010-04-23 01:51:04 UTC
Permalink
Post by Jamie
Post by Erwin Ahlers
how to use some find file
functions when I use an URL like file name, e.g. \\server\dir1\*.pas
The normal findFirst or findFirstFile don't accept this.
You need to use the Wide version of FindFirstfile.
FindFirstFileW
I do not believe you. Do you have anything to back up that claim?
--
Rob
Erwin Ahlers
2010-04-23 21:19:53 UTC
Permalink
Hi,
I found out the following: When I give an exact file name, without any
wildcard, it works always. Also with \\Server\path\name.
Looking for all files in a directory, \\Server\path\*, works also. But
something like \\Server\path\file*.pas doesn't work. I tried with
several characters before the path, but nothing worked.
For my current problem I could implement a workaround that uses just
full names. So in principle the problem is solved. Even I don't
understand completely why something like file*.pas doesn't work.

Erwin
Jamie
2010-04-24 11:43:05 UTC
Permalink
Post by Erwin Ahlers
Hi,
I found out the following: When I give an exact file name, without any
wildcard, it works always. Also with \\Server\path\name.
Looking for all files in a directory, \\Server\path\*, works also. But
something like \\Server\path\file*.pas doesn't work. I tried with
several characters before the path, but nothing worked.
For my current problem I could implement a workaround that uses just
full names. So in principle the problem is solved. Even I don't
understand completely why something like file*.pas doesn't work.
Erwin
As was stated before about lauguage differences..

When reading help files, all examples are assumed to be in C/C++ language.
the double "\\" is throwing you..
I'm not going to give a C/C++ leason here, so when reading help
files meant for C/++ remember to use only 1 "\" when grouped together
in a quoted string.

look into the use of '\?\unc\xxxx' and the (W) version of FindFirstFile.
Rudy Velthuis
2010-04-24 21:36:20 UTC
Permalink
Post by Jamie
When reading help files, all examples are assumed to be in C/C++
language. the double "\\" is throwing you..
No, it is not.
--
Rudy Velthuis http://rvelthuis.de

"A picture is worth a thousand words (which is why it takes a
thousand times longer to load...)"
-- Eric Tilton, Composing Good HTML
Jamie
2010-04-24 11:24:48 UTC
Permalink
Post by Rob Kennedy
Post by Jamie
Post by Erwin Ahlers
how to use some find file
functions when I use an URL like file name, e.g. \\server\dir1\*.pas
The normal findFirst or findFirstFile don't accept this.
You need to use the Wide version of FindFirstfile.
FindFirstFileW
I do not believe you. Do you have anything to back up that claim?
Yes. the Win32 Help file..


Where do you think I got that from ?

Taken from the help file


There is a default string size limit for paths of MAX_PATH characters.
This limit is related to how the FindFirstFile function parses paths. An
application can transcend this limit and send in paths longer than
MAX_PATH characters by calling the wide (W) version of FindFirstFile and
prepending "\\?\" to the path. The "\\?\" tells the function to turn off
path parsing; it lets paths longer than MAX_PATH be used with
FindFirstFileW. This also works with UNC names. The "\\?\" is ignored as
part of the path. For example, "\\?\C:\myworld\private" is seen as "
C:\myworld\private", and "\\?\UNC\bill_g_1\hotstuff\coolapps" is seen as
"\\bill_g_1\hotstuff\coolapps".


Read it as you wish. The way I read that, the (W) version is required.
Rudy Velthuis
2010-04-24 21:38:02 UTC
Permalink
Post by Jamie
Read it as you wish. The way I read that, the (W) version is
required.
Only for very long path strings. Not for UNCs in general.
--
Rudy Velthuis http://rvelthuis.de

"If you haven't got anything nice to say about anybody, come sit
next to me." -- Alice Roosevelt Longworth (1884-1980)
Bart
2010-04-25 06:42:41 UTC
Permalink
Op Sat, 24 Apr 2010 07:24:48 -0400 schreef Jamie
<***@charter.net>:

Just tested this.
FindFirstFileA happily returns filenames like 'some.doc' if you supply
'\\server\shared\temp\*.doc' as the path.
(Tested with freepascal 2.4.1. on Win9x)

Bart
--
Bart Broersma
***@tiscali.nl
(ff _ANTISPAM_ wegpoetsen uit dit adres natuurlijk)
Hans-Peter Diettrich
2010-04-23 19:01:50 UTC
Permalink
Post by Rob Kennedy
Post by Jamie
You need to use the Wide version of FindFirstfile.
FindFirstFileW
I do not believe you. Do you have anything to back up that claim?
The old Delphi WinAPI help files, older MSDNlib...

The current MSDN is not really reliable, too .NET centric :-(

DoDi
Rudy Velthuis
2010-04-24 21:35:10 UTC
Permalink
Post by Jamie
You need to use the Wide version of FindFirstfile.
Says who?
Post by Jamie
Also, beware of translating C/C++ over to delphi when reading
data with in "xxxx". You must remember that C likes to use
control characters in the strings..
things like "\\" actually are "\"
I think you should read up on UNCs.

http://en.wikipedia.org/wiki/Path_%28computing%29#Uniform_Naming_Convention
--
Rudy Velthuis http://rvelthuis.de

"Some problems are so complex that you have to be highly
intelligent and well informed just to be undecided about them."
-- Laurence J. Peter
Loading...