[Oorexx-devel] SysFileTree under unix : parameters tattrib and nattrib not supported ?

2012-02-11 Thread Jean-Louis Faucher
Under MacOs, I had an invalid routine call returned by SysFileTree
because of a path too long.
The call to variablePoolGetVariable  returned a NULL retriever.
I did not investigate more here, because I saw that the current file path
was longer than the buffer size.
After replacing MAX by PATH_MAX where appropriate, I had no more error.

My next step was to run test4.rex provided by Jerry, but I discover that
the Unix version of SysFileTree takes only 3 arguments... So no way to pass
tattrib and nattrib under Unix ?

I'm currently running test4.rex without tattrib on my Mac. Will tell you if
I have an error.

Jean-Louis

-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2012/2/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7518]
sandbox/jlf/trunk/extensions/rexxutil/platform/ unix/rexxutil.cpp
To: oorexx-...@lists.sourceforge.net


Revision: 7518
 http://oorexx.svn.sourceforge.net/oorexx/?rev=7518view=rev
Author:   jfaucher
Date: 2012-02-11 13:45:14 + (Sat, 11 Feb 2012)
Log Message:
---
A possible fix for SysFileTree bug 3405740, but not yet the ultimate good
fix.
Some buffers are too small (MAX=256).
Now using the predefined PATH_MAX, but a buffer overflow is still possible :
http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html

Modified Paths:
--
   sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp

Modified: sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
===
--- sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
 2012-02-10 01:49:33 UTC (rev 7517)
+++ sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
 2012-02-11 13:45:14 UTC (rev 7518)
@@ -385,9 +385,9 @@
SHVBLOCK shvb; /* Request block for RxVar*/
size_t stemlen;/* Length of stem */
size_t vlen;   /* Length of variable value   */
-char TargetSpec[MAX+1];/* Target filespec*/
-char truefile[MAX+1];  /* expanded file name */
-char Temp[MAX+80]; /* buffer for returned values */
+char TargetSpec[PATH_MAX+1];   /* Target filespec*/
+char truefile[PATH_MAX+1]; /* expanded file name */
+char Temp[PATH_MAX+80];/* buffer for returned values */
char varname[MAX]; /* Buffer for variable name   */
size_t nattrib;/* New attrib, diff for each  */
 } RXTREEDATA;
@@ -1282,7 +1282,7 @@
  size_t   options )   /* Search and output format   */
   /* options*/
 {
-  char  tempfile[MAX+1];   /* Used to hold temp file name*/
+  char  tempfile[PATH_MAX+1];  /* Used to hold temp file name*/
  DIR *dir_handle; /* Directory handle   */
  struct stat finfo;   /* file information   */
  char * filename;

This was sent by the SourceForge.net collaborative development platform,
the world's largest Open Source development site.


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Oorexx-svn mailing list
oorexx-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-svn
--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] SysFileTree under unix : parameters tattrib and nattrib not supported ?

2012-02-11 Thread Mark Miesfeld
Hi Jean-Louis,

That is exactly where I thought the problem might be, in the ldp-Temp
buffer, because of a very long path plus adding the attributes and long
date.

But I only tested on Windows.  On Windows it is impossible to create a
directory plus filename plus attributes that would over-run the buffer, and
I didn't go farther.

That's a good pointer in the commit you made to the discussion on PATH_MAX,
but the discussion is incorrect on Windows, as far as I can see.

The test I did was to repeatedly create subdirectories with long names.  I
was trying to create a situation where the full path name was very long,
and then have full directory name + long file name + attributes  MAX +
80.  It simply is not possible on NTFS in Windows.  (But I don't know about
FAT.) When you get up to the limit and try to create either a directory
name that will go past the limit, or put a file into a directory where the
directory name + file name is longe than the limit, the OS refuses and says
too long.

By the way, rather than change a bunch of different places where MAX is
used, I think a better fix is to change the define of MAX

#define MAX 256

should be

#define MAX PATH_MAX


A better thing to do, which I think I'll do over the weekend, is to change
the define of MAX, and to change all the sprintf() calls to snprintf()
calls.

--
Mark Miesfeld
On Sat, Feb 11, 2012 at 6:31 AM, Jean-Louis Faucher
jfaucher...@gmail.comwrote:

 Under MacOs, I had an invalid routine call returned by SysFileTree
 because of a path too long.
 The call to variablePoolGetVariable  returned a NULL retriever.
 I did not investigate more here, because I saw that the current file path
 was longer than the buffer size.
 After replacing MAX by PATH_MAX where appropriate, I had no more error.

 My next step was to run test4.rex provided by Jerry, but I discover that
 the Unix version of SysFileTree takes only 3 arguments... So no way to pass
 tattrib and nattrib under Unix ?

 I'm currently running test4.rex without tattrib on my Mac. Will tell you
 if I have an error.

 Jean-Louis

 -- Forwarded message --
 From: jfauc...@users.sourceforge.net
 Date: 2012/2/11
 Subject: [Oorexx-svn] SF.net SVN: oorexx:[7518]
 sandbox/jlf/trunk/extensions/rexxutil/platform/ unix/rexxutil.cpp
 To: oorexx-...@lists.sourceforge.net


 Revision: 7518
  http://oorexx.svn.sourceforge.net/oorexx/?rev=7518view=rev
 Author:   jfaucher
 Date: 2012-02-11 13:45:14 + (Sat, 11 Feb 2012)
 Log Message:
 ---
 A possible fix for SysFileTree bug 3405740, but not yet the ultimate good
 fix.
 Some buffers are too small (MAX=256).
 Now using the predefined PATH_MAX, but a buffer overflow is still possible
 :
 http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html

 Modified Paths:
 --
sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp

 Modified: sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
 ===
 --- sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
  2012-02-10 01:49:33 UTC (rev 7517)
 +++ sandbox/jlf/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp
  2012-02-11 13:45:14 UTC (rev 7518)
 @@ -385,9 +385,9 @@
 SHVBLOCK shvb; /* Request block for RxVar*/
 size_t stemlen;/* Length of stem */
 size_t vlen;   /* Length of variable value   */
 -char TargetSpec[MAX+1];/* Target filespec*/
 -char truefile[MAX+1];  /* expanded file name */
 -char Temp[MAX+80]; /* buffer for returned values */
 +char TargetSpec[PATH_MAX+1];   /* Target filespec*/
 +char truefile[PATH_MAX+1]; /* expanded file name */
 +char Temp[PATH_MAX+80];/* buffer for returned values */
 char varname[MAX]; /* Buffer for variable name   */
 size_t nattrib;/* New attrib, diff for each  */
  } RXTREEDATA;
 @@ -1282,7 +1282,7 @@
   size_t   options )   /* Search and output format   */
/* options*/
  {
 -  char  tempfile[MAX+1];   /* Used to hold temp file name*/
 +  char  tempfile[PATH_MAX+1];  /* Used to hold temp file name*/
   DIR *dir_handle; /* Directory handle   */
   struct stat finfo;   /* file information   */
   char * filename;

 This was sent by the SourceForge.net collaborative development platform,
 the world's largest Open Source development site.



 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.