Problem with DIRECTORY() function

[codemaker]

I use xHarbour and some Web-library for my Web applications for many years by now.

I have one folder which holds the PDF files for calculated W2 forms.
Each file name starts with the client code, which is 3 character.
The listed files in folder looks like this (part of listing):

A27_0154_USW2_4CR_1231.PDF
A27_0154_USW2_4CR_1231.PDF
A28_0154_USW2_4CR_1231.PDF
A28_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A24_0154_USW2_4CR_1231.PDF
A24_0154_USW2_4CR_1231.PDF
A24_0154_USW2_4CR_1231.PDF
A24_0154_USW2_4CR_1231.PDF
A29_0154_USW2_4CR_1231.PDF
A24_0154_USW2_4CR_1231.PDF
...

The folder name is for example: cFind := "c:\pdffiles\W2forms\"
The client code I want to extract: cUserID := "A29"
When I want to extract only the PDF files which starts with client code for example "A29" I do it like this
af1 := cFind + cUserID + "*.PDF"
aMyFiles := DIRECTROY( af1 )

I expect in "aMyFiles" array all PDF files which name starts with "A29"
On my huge surprise the array contains something like tihs, after I made some debug breakpoint:


I cannot even think to explain how this happened???
This error cause me a lot of problems, I simply cannot relay on DIRECTORY() function any more. If some clients can see some other clinets W2 forms, I can close my business in the payroll area.... So I disabled for now this feature.

I tested this behaviour and select another user ID, for example "A24" and it shows all A24 but also some of A29 and A27... And so forth.
For some user ID it shows ok, only what I select to be the USer ID....

I can't find any pattern, maybe the length of file names??

For now I will "filter" this wrong results

Code: Select all  Expand view

FOR := 1 to LEN(aMyFiles)
      IF UPPER(SUBS(aMyFiles[i][1],1,3) == UPPER(cUserID)
            - use this element (file) for workig with
      ENDIF
NEXT i
 

which is not I ever dreamed of as necessary after the DIRECTORY() function call...
Not to mention it took me almost 10 days of hard tries to find out what causes the list to be "mixed" with different user ID PDF files. Finally, I was desperate and checked what exactly comes out as the result of DIRECTORY() function. It is not enaugh to say I was astonished..

Any similar experiences?
I am totaly confused...

[Rick Lipkin]

CodeMaker

Directory() is a (x)Harbour function and not part of FWH .. Have you updated or changed your (x)Harbour compiler recently ?

The xHarbour newsgroup is :
http://groups.google.com/group/comp.lan ... pics?gvc=2

The Harbour newsgroup is :
http://groups.google.com/group/harbour-users/topics

Rick Lipkin

[FranciscoA]

Codemaker,

I think this function retrieves entire names of files, not partially names of them. Maybe I Wrong.

I allways have used the technic you describes, on others similar cases.

In the other hand, I think this could be a new feature of this function for to be implementation, if it so considers the xHarbour's creators.

Regards

[codemaker]

Yes, I was confused because whatever kind of file names this function retrieves, it should obey the given pattern.
If this pattern is "A26*.PDF" I don't see any reason this function return any other file name which does not start with "A26"

[Enrico Maria Giordano]

To blame the compiler is the easy way, almost the wrong one.

EMG

[Antonio Linares]

Boris,

I think it may be related with the use of long filenames because this example works fine with both Harbour and xHarbour:

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   local aFiles := Directory( "b*.prg" )

   MsgInfo( Len( aFiles ) )

return nil

[ukoenig]

Antonio,

YES, it seems to be a Problem with long Filenames.



It means to scan all Array-elements for "A29" ? :



Best Regards
Uwe

[codemaker]

Just a sample what exactly is wrong here.
It is the way how Windows OS handle the long filenames.

1. Look how windows "translate" the long file names and creates the short file names abreviation:

Notice how the short names all start with "A29" for no logical reason

2. Now, according with the method Windows OS creates short file names abowe, this is what we get when using DIRECTORY("A29*.PDF")



And I am affraid this is not the end:
This "filtering method" when we use long file names is probably affected by
COPY a29*.pdf c:\somefolder - who nows what will be copied

Also, even biger problem, sonsider the nightmare if we delete the files by using "filtering":
DEL a29*.pdf - we will finished with some other files deleted too!!!!!

The same potentialo problem with
REN a29*.pdf a25*.pdf - who knows what the result will be.....

Scary.

[StefanHaupt]

Codemaker,

this sample is working fine here. See the images.

Code: Select all  Expand view

#include "Fivewin.ch"
#include "xBrowse.ch"

function main ()

  local aDir, aDirAll
  local cFind := ".\Testdir\"
  local cUserID := "A29"
  local af1 := cFind + cUserID + "*.PDF"

  aDir := Directory (af1)
  ? "Searching " + af1, "Found: " + Str (Len(aDir))
  xBrowser aDir

  aDirAll := Directory (cFind+"*.pdf")
  ? "Searching all" + af1, "Found: " + Str (Len(aDirAll))
  xBrowser aDirAll


  RETURN (0)

[Otto]

Hello Boris,

As all is that complex it is very important to have good beta testers for your software.

BTW, did you try using Lfn2Sfn(cDir) with the directory-function?

Best regards,
Otto

[Enrico Maria Giordano]

And I am affraid this is not the end:
This "filtering method" when we use long file names is probably affected by
COPY a29*.pdf c:\somefolder - who nows what will be copied

Also, even biger problem, sonsider the nightmare if we delete the files by using "filtering":
DEL a29*.pdf - we will finished with some other files deleted too!!!!!

The same potentialo problem with
REN a29*.pdf a25*.pdf - who knows what the result will be.....

Scary.

I can't believe this! Can you test the above commands with your filenames and let us know, please?

EMG

[codemaker]

Hello Boris,

As all is that complex it is very important to have good beta testers for your software.

BTW, did you try using Lfn2Sfn(cDir) with the directory-function?

Best regards,
Otto

Hi Otto,
All my software is tested for 8 years (web app) and more than 14 years (desktop)
Two months ago, I implemented this new function to print PDF from WEB and then I spoted the problem. Therefore, I am sure, it is not my app problem, epsecially one line of code cannto be written wrong ( DIRECTORY(cFilterString)

Then I tested the same PDF access from desktop application - same problem.

The I checked what DOS shows and the images says all. DOS simply create the short fle name

I didn't try Lfn2Sfn() function yet and I don't think I will, because I will additionaly filter the DIRECTORY() returned array and finally have the correct names

Regards
Boris

[codemaker]

And I am affraid this is not the end:
This "filtering method" when we use long file names is probably affected by
COPY a29*.pdf c:\somefolder - who nows what will be copied

Also, even biger problem, sonsider the nightmare if we delete the files by using "filtering":
DEL a29*.pdf - we will finished with some other files deleted too!!!!!

The same potentialo problem with
REN a29*.pdf a25*.pdf - who knows what the result will be.....

Scary.

I can't believe this! Can you test the above commands with your filenames and let us know, please?

EMG

I will today and will post here

[StefanHaupt]

And I am affraid this is not the end:
This "filtering method" when we use long file names is probably affected by
COPY a29*.pdf c:\somefolder - who nows what will be copied

Also, even biger problem, sonsider the nightmare if we delete the files by using "filtering":
DEL a29*.pdf - we will finished with some other files deleted too!!!!!

The same potentialo problem with
REN a29*.pdf a25*.pdf - who knows what the result will be.....

Scary.

Boris,

I don´t see any wrong behavior, neither from dos nor from xHarbour. Did you test my sample ?

Dos-commands are also working here (Win7)

[codemaker]

Boris,

I don´t see any wrong behavior, neither from dos nor from xHarbour. Did you test my sample ?

Dos-commands are also working here (Win7)

Stefan,
This is exactly what scares me.
On some system, it works, on some other doesn't
I cannot find the difference.

For example, my WebApp is running on many servers (computers), starting from XP and then Wndows server 2003, Windows server 2008, also on Windows7....
Some of my clients doesn't complain at all, some of them does (one of them Windows server 2003). My machine (Windows 7) also shows the problem, yours doesn't....

I didn't test your sample, because it is the same as what I posted, I don't see any basic difference?
Your sample works ok, and your DOS shows properly.
Mine doesn't show the proper result because I can see DOS shows problem either...

I suspect the cause of the problem is in Windows OS which handles short-long file names on some way which the function DIRECTORY() interprets wrongly, while following DOS OS. This will not be solved or changed by M$, so what's left is up to the creators of xHB, maybe they should add the code which additionaly filters the resulting array from DIRECTORY() function...

I am not sure what to say, but to use the additional filtering before presenting the result to the program user.

ragards
Boris