#814 date, time, size missing from SysFileTree results

4.1.3
closed
Mark Miesfeld
none
5
2013-07-09
2009-09-13
D.M.Wooster
No

SysFileTree is still documented as returning the date, time, filesize, flags, and filepath/name.
This is the way it has always worked. Now, it never returns date, time, or filesize.

ooRexx Version: 4.0.0
Platform: Linux: Debian 5.0.2a (Lenny) on x86 (32-bit)

This is a new machine, which has never before had any Rexx on it.
Just to be sure, I uninstalled and reinstalled it

dpkg -P ooRexx

dpkg -i ooRexx-4.0.0.i586.deb

Still fails to provide dates, times, or filesizes.

Attached, please find a demonstration program and its output.

Discussion

1 2 > >> (Page 1 of 2)
  • D.M.Wooster
    D.M.Wooster
    2009-09-13

    program to demonstrate bug

     
    Attachments
  • D.M.Wooster
    D.M.Wooster
    2009-09-13

    Unfortunately, this latest SourceForge UI doesn't seem to have a way to attach more than one file to a bug report. Please email if you want sample output.

     
  • Rick McGuire
    Rick McGuire
    2009-09-16

    I'm not sseing anything unexpected from this program. For all options that turn more than just the file name, the information is there.

     
  • Rick McGuire
    Rick McGuire
    2009-09-17

    Mark, I don't have a Debian system to test on, but this is working ok on Fedora. I have a suspicion the problem might be a caused by the sprintf() function. The sprintf() call on line 1213 uses ldp-Temp as both the target buffer for the formatting and as one of the input arguments. I suspect that's causing this to fail.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    Rick,

    I've been meaning to boot up a Debian system to look at this. Just kept putting it off. <grin> I'll test it today.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    This seems to work fine at least on Kubuntu 8.10 32-bit. I'm using the 4.0.0 release

    / getFiles.rex /

    j = SysFileTree('.', files., "FST")
    do i = 1 to files.0
    say files.i
    end

    Output (some of it there are a lot of files):

    miesfeld@Osprey:~/work.ooRexx/ooTest/temp.test.4.0.0$ rexx getFiles.rex
    09/08/15/20/09 3427 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/directory.structure.for.tests
    09/08/15/20/09 4692 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/testOORexx.rex
    09/09/17/08/53 85 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/getFiles.rex
    09/08/15/20/09 3477 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.sh
    09/08/15/20/09 7414 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ReadMe.first
    09/08/15/20/09 77348 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ooTest.frm
    09/08/15/20/09 40020 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/worker.rex
    09/08/15/20/09 2397 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.bat
    09/08/15/20/09 1550 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/Expected.Results
    09/08/15/20/09 8977 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/building.frm
    09/08/15/20/09 11626 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/CPLv1.0.txt
    09/08/15/20/09 5116 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/doc/Release.notes
    09/08/15/20/09 323731 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/doc/ooTestQuick.pdf
    09/08/15/20/09 4679 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ooRexx/SimpleTests.testGroup

    Sorry, I didn't notice your example program, I'll try that.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    Your example program also seems to work fine for me on Kubuntu. I didn't look super sharp at the flags you are supplying, but a cursory checks shows the output to be what is expected.

    What is your default shell? I do have a pure Debian system I can check on. I only have a 64-bit version and I think it is at 5.0.0, but that should be close enough.

    miesfeld@Osprey:~/work.ooRexx/ooTest/temp.test.4.0.0$ rexx sftbug.rex | more
    0
    8/15/09 8:09p 3427 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/directory.structure.for.tests
    8/15/09 8:09p 4692 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/testOORexx.rex
    9/17/09 8:53a 85 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/getFiles.rex
    8/15/09 8:09p 3477 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.sh
    8/15/09 8:09p 7414 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ReadMe.first
    8/15/09 8:09p 77348 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ooTest.frm
    8/15/09 8:09p 40020 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/worker.rex
    9/17/09 9:01a 1175 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/sftbug.rex
    8/15/09 8:09p 2397 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.bat
    8/15/09 8:09p 1550 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/Expected.Results
    8/15/09 8:09p 8977 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/building.frm
    8/15/09 8:09p 11626 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/CPLv1.0.txt
    8/15/09 8:11p 0 -rw------- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/FILE
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/doc
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ooRexx
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/misc
    8/15/09 8:13p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/framework
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/bin
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/external
    0
    8/15/09 8:09p 3427 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/directory.structure.for.tests
    8/15/09 8:09p 4692 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/testOORexx.rex
    9/17/09 8:53a 85 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/getFiles.rex
    8/15/09 8:09p 3477 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.sh
    8/15/09 8:09p 7414 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ReadMe.first
    8/15/09 8:09p 77348 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/ooTest.frm
    8/15/09 8:09p 40020 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/worker.rex
    9/17/09 9:01a 1175 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/sftbug.rex
    8/15/09 8:09p 2397 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/setTestEnv.bat
    8/15/09 8:09p 1550 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/Expected.Results
    8/15/09 8:09p 8977 -rwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/building.frm
    8/15/09 8:09p 11626 -rw-r--r-- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/CPLv1.0.txt
    8/15/09 8:11p 0 -rw------- /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/FILE
    0
    8/15/09 8:09p 4096 drwxr-xr-x /home/miesfeld/work.ooRexx/ooTest/temp.test.4.0.0/doc

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    I hate that Debian distribution. Why the heck people use it, I don't understand. <grin>

    Okay, on the pure Debian distribution, the test program doesn't display the file size or time. Only the attributes and names.

    I'll look into it this afternoon.

     
  • Rick McGuire
    Rick McGuire
    2009-09-17

    There's probably a simple fix for this. Just allocate a local buffer for formatting the time stamp and size rather than reuse the ldp->Temp field.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    I built from trunk on the Debian system and the example program works fine:

    09/09/17/10/30 1175 -rw-r--r-- /home/miesfeld/work.ooRexx/wc/sftbug.rex
    09/04/09/14/29 904388 -rw-r--r-- /home/miesfeld/work.ooRexx/wc/ooRexx-4.0.0-4354.x86_64.debian50.deb
    09/09/17/11/06 940016 -rw-r--r-- /home/miesfeld/work.ooRexx/wc/oorexx_4.0.0-5188_amd64.deb
    09/09/17/10/58 20480 drwxr-xr-x /home/miesfeld/work.ooRexx/wc/ooRexx.4.0.0.beta
    09/09/17/11/05 20480 drwxr-xr-x /home/miesfeld/work.ooRexx/wc/ooRexx-4.0.0
    0

    I wonder if there is some subtle library difference between the pure Debian system and the Kubuntu system?

    In the releases before 4.0.0, a deb package builit on Kubuntu would not work on Debian, and vice-versa. It might be better to just build a separate package for Debian. If it is a library difference, there could be some other, unencountered, problem.

    I'll try your change Rick, but I guess I need to build it on the Kubuntu systetem to really prove anything.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-17

    Rick,

    I built a version on Kubuntu using a local buffer to do the formatting. One version from the release code base and one from trunk.

    On the one built from the release code base, now back on Debian, the file times and sizes show with the T and L flags. With the O flag, the entire line is blank. ;-)

    With the version built from trunk, the T and L flags produce perfectly correct output. The O flag lines have unprintable characters in them.

    With the release code base, I guess the line is not blank, it always has a length of 1 and the actual char is always a 4. With the trunk code base, the length of the line is always 3, but the chars vary.

    With both code bases, release and trunk, when built here on the Debian system, SysFileTree works without any detectable errors. I'm more inclined to think that there is some library incompatibility, or a compiler difference. Although, there are also a lot of warnings for sprintf() about the variables not matching the format specifiers.

     
  • Rick McGuire
    Rick McGuire
    2009-09-17

    Ok, that is one serious library incompatibility. When the O option is specified, the line is created using a simple strcpy() call.

     
  • Mark Miesfeld
    Mark Miesfeld
    2009-09-30

    Took a while to get back to this. (Actually took me a while to get a 32-bit Debian 5.0 installed.)

    Doug, I uploaded a Debian 5.0 specific set of deb packages to SourceForge. A 32-bit and 64-bit version. With the packages built directly on a Debian system, rather than on a Kubuntu system, the SysFileTree() problem goes away. Your test program works correctly. If you re-install using one of those packages, SysFileTree() should work again for you.

    Rick,

    "Ok, that is one serious library incompatibility. When the O option is specified, the line is created using a simple strcpy() call. "

    Yes, a library incompatibility explanation seems a little weak because of that. I'm not sure what's at the bottom of this. However, the 32-bit version of Debian 5.0 behaved exactly like the 64-bit version. If I install the deb package built on Kubuntu, Doug's test program fails. When I built the package directly on the system, the test program worked correctly.

    I'll leave this open since we don't really seem to have an answer to the cause. In the mean time, for the 4.0.0 release using the packages I just uploaded seems a viable work around.

     
  • Swifty
    Swifty
    2010-03-31

    Is there a way for me to concur with this bug, to raise its priority? I badgered my ISP to install oorexx 4.0 and fell foul of this. They might get a little twitchy if I have to ask them to install from source to get to 4.0.1 - since they were the first ISP that would install rexx for me, I'm desperate not to upset them.

     
  • Mark Miesfeld
    Mark Miesfeld
    2010-03-31

    Steve, wait a few days (until this weekend.) I'll build a 32-bit and 64-bit package specifically on Debian 5.0 and test that this bug is not present. Then you can have your ISP install it with relative confidence.

    In fact, add a comment here as to exactly what OS the ISP is running.

     
  • Swifty
    Swifty
    2010-03-31

    I'm not good at deducing what the system is; all I know is that one of the affected ones is Debian 5.0.4; uname -r gives 2.6.26-2-amd64 (the other system gives 2.6.22.19-vs2.2.0.7-xeon-bigmem)

     
  • Mark Miesfeld
    Mark Miesfeld
    2010-03-31

    Steve,

    I put the 32-bit and 64-bit packages for Debian 5.0 on SourceForge a little bit ago. I tested for this bug with both packages, and had no problems. Have your ISP use the appropriate one, 32 or 64 bit. There should be no problem, with this specific bug.

     
  • Geoff Stevens
    Geoff Stevens
    2010-06-16

    I have a user report for this very bug using

    rexx -v
    Open Object Rexx Version 4.0.0
    Build date: Aug 9 2009
    Addressing Mode: 64

    ]$ uname -a
    Linux irsdog 2.6.33.5-112.fc13.x86_64 #1 SMP Thu May 27 02:28:31 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

    That's a system updated to FC13, user is unsure what level he started at

     
  • Mark Miesfeld
    Mark Miesfeld
    2010-06-16

    "I have a user report for this very bug using"
    ...
    "That's a system updated to FC13, user is unsure what level he started at"

    Well drat, I was hoping that this was just a wierd Debian thing. It so happens I just installed a FC13 64-bit system last weekend. I'll take a look and see if I can reproduce the bug.

     
  • Geoff Stevens
    Geoff Stevens
    2010-06-16

    He'd installed an FC12 rpm of 4.0.0 from the Fedora repository onto the FC13.

    After installing 4.0.1 from the sourceforge site, problem is resolved.

    So, library incompatibility again...

     
  • Mark Miesfeld
    Mark Miesfeld
    2012-02-03

    On Debian, we see that installing a package actually buitl on a Debian system rather installing a package built on Ubuntu or Kunbuntu resoloves this. I've examined the code several times and the code appears correct.

    As to Fedora, we can not, and have never said we would, support packages not built by the development team and downloaded from SourceForge.

    So, the resolution to this problem is to install the correct package.

     
  • Mark Miesfeld
    Mark Miesfeld
    2012-07-30

    I'm opening this back up, just to make a few notes.

    With the re-implementation of SysFileTree I just finished this bug goes away. I built a deb package on a Kubuntu system and one on an Ubuntu system.

    When I run the test program using the older SysFileTree() implementation, the bug still shows, the date time info is missing. When I rerun the test program using the new implementation, no bug. Same results with both the Kubuntu and Ubuntu packages.

    I think Rick was correct when he said:

    Mark, I don't have a Debian system to test on, but this is working ok on
    Fedora. I have a suspicion the problem might be a caused by the sprintf()
    function. The sprintf() call on line 1213 uses ldp-Temp as both the target
    buffer for the formatting and as one of the input arguments. I suspect
    that's causing this to fail.

    Anyhow, it is reassuring to be able to produce the bug and then see it fixed in the current code.

    I'll mark this fixed and pending when I commit.

     
  • Mark Miesfeld
    Mark Miesfeld
    2012-07-30

    Committed revision 8126 in trunk

    Testing looks good, but will do more testing before committing to the 4.1 fixes branch

     
  • Mark Miesfeld
    Mark Miesfeld
    2012-08-09

    Committed revision 8175. 4.1 fixes branch

     
  • Mark Miesfeld
    Mark Miesfeld
    2013-07-09

    • status: pending --> closed
    • Pending work items: --> none
     
1 2 > >> (Page 1 of 2)


Anonymous


Cancel   Add attachments