FindFirst(File) mit url
Erwin Ahlers
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
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
news:224e98f3-2f1e-4354...@g30g2000yqc.googlegroups.com...
> 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.)
> 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
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
> Erwin Ahlers wrote:
>> 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.
>
>
> FindFirstFileW
I do not believe you. Do you have anything to back up that claim?
--
Rob
Erwin Ahlers
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
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.
Jamie
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.
Hans-Peter Diettrich
>> 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
> You need to use the Wide version of FindFirstfile.
Says who?
> 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
Rudy Velthuis
> 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
Rudy Velthuis
> 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
<jamie_ka1lpa_not_v...@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
broersma.ju...@tiscali.nl
(ff _ANTISPAM_ wegpoetsen uit dit adres natuurlijk)