Question FILE-INFO alternative

PatrickTingen

New Member
As I was trying to read all files in a folder with their attributes, it occurred to me that there should be a faster way to do this than examining each file in the folder with FILE-INFORMATION and then pulling the attributes like last modification date and file size from it. So I did an OS-COMMAND SILENT VALUE('dir /s > tempfile.txt') and opened the tempfile.txt and parsed the text inside.

All well? Well, not really. Although this was insanely fast, compared to the FILE-INFO solution, it also was insanely regionally bounded. I tried it on another computer and it immedately broke because of different regional settings in the date. My windows date format is set as dd/mm/yyyy but on the other computer it was dd-mm-yyyy. And there are probably more differences.

So is there another - fast! - way of retrieving file information of the files in a folder? perhaps using .Net classes?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Hi Patrick,

It would be useful to know your platform requirements. Is this for DataDigger? Does it need to run cross-platform or are you content with a solution that works only on Windows, or perhaps wherever .Net Core is available?

If Windows, you could shell out and list files with PowerShell (e.g. Get-ChildItem -Path D:\path). I haven't tried this approach but it might be helpful that it returns a list of objects rather than just text.

Looking forward to hearing other answers to this one. :)
 

PatrickTingen

New Member
No this is not for DataDigger. Every now and then I need to do some other work as well ;)

Cross platform is not a requirement since this client solely runs on Windows machines. I looked at powershell as well but that solution does not lead me anywhere since it is also regionally dependent.

TiKAj8N[1].png

If you look on your system the dates are probably m-d-y and perhaps using slashes instead of dashes.

The problem with OS-DIR is that it does not provide information about modification date/time and file sizes. I have to obtain that information via the file-info system handle which is getting slow on folders. I rewrote the procedure to read the folder and it went back from 6 seconds to near instant. But I am not confident that it will work on all configurations.
 

PatrickTingen

New Member
I also found this KB entry to be valuable. You can use

MESSAGE
System.Globalization.CultureInfo:CurrentCulture:DateTimeFormat:ShortDatePattern /* dd/MM/yyyy */
System.Globalization.CultureInfo:CurrentCulture:DateTimeFormat:DateSeparator /* / */
VIEW-AS ALERT-BOX.


To find date format and date separator. Based on that, one could change the parsing strategy.

For now, my solution is good enough, but it would not be good enough to use - for example - in my DataDigger since that runs on a wild variety of machines. For my client my current solution is good enough because it will only run on 2 machines.
 
Hi,

In a way to analyse some file I write this:

Code:
/* variable character */
DEFINE VARIABLE cLine    AS CHARACTER   NO-UNDO.
DEFINE VARIABLE cCommand AS CHARACTER   NO-UNDO. /* CMD command */

/* search .p & .w file*/
cCommand = "CD /D " + cPath + "&& DIR *.w *.p" .

INPUT THROUGH VALUE(ccommand) CONVERT SOURCE "UTF-8". /* exect the command */
REPEAT:
    IMPORT UNFORMATTED cLine.
    
    /* Reading of the command */

    IF ENTRY(1, cLine, " ") <> " "
        AND  LOOKUP("<DIR>", cLine, "  ") = 0
        AND  NUM-ENTRIES(cLine, ".") > 1
        AND  INDEX(cLine, "_save.w") = 0
        AND  INDEX(cLine, "_save.p") = 0
        AND  INDEX(cLine, ".w.")     = 0
        AND  INDEX(cLine, ".w-")     = 0
        AND  INDEX(cLine, ".p.")     = 0
        AND  INDEX(cLine, ".p-")     = 0 THEN DO:
            
            CREATE TT-LISTE.
            ASSIGN
                TT-LISTE.dDate   = DATE(SUBSTRING(cLine, 1, 10))
                TT-LISTE.cTime   = SUBSTRING(cLine, 13, 5)
                TT-LISTE.iTaille = INT(TRIM(SUBSTRING(cLine, 18, 17)))
                TT-LISTE.cName   = TRIM(SUBSTRING(cLine, 36))
                TT-LISTE.cFld    = TT-FLD.cFldName .
            
            /* Number of program found */
            IF ENTRY(2, cLine, ".") = "w" THEN
                iNbw = iNbw + 1.
            ELSE
                iNbp = iNbp + 1.

            iVtotal = iVtotal + TT-LISTE.iTaille .
    END.

END.
INPUT CLOSE.
It was eavy but it works.
 

tamhas

ProgressTalk.com Sponsor
I have to wonder what you are doing that the performance of file-info is an issue ...
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I have to wonder what you are doing that the performance of file-info is an issue ...
I'd say it depends on the number of files you want to examine. With a limited number of files, FILE-INFO is fine. However when we use it to build a compile list when building our application (10,000+ compile units), it adds up to a fair bit of time, even when the directories are local to the client.
 

tamhas

ProgressTalk.com Sponsor
It just seems to me that examining 10,000 files and not actually doing anything with them is a pretty unusual requirement ... I have to wonder if there aren't better OS tools for the purpose (he says, having built similar things).
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
It just seems to me that examining 10,000 files and not actually doing anything with them is a pretty unusual requirement ... I have to wonder if there aren't better OS tools for the purpose (he says, having built similar things).
A bit off-topic, but in this case the purpose of FILE-INFO is to get their fully-qualified paths. And I'm sure there could be OS-specific solutions in some cases, but our solution has to work on a variety of platforms, so the developer chose FILE-INFO.
 
Top