Hi Jerome,
as you said, this file is out of date (1.0.8a). Version 1.1.0 will hopefully be published in a few months.
I just had a look at the file and noticed that there are some malformed characters inside, I assume they came from a wrong codepage setting, they should represent ä ö ü ß.
I just fixed this so that it is correct. Update enclosed.
Could you please check if this helps?
Willi
Sent: Friday, March 21, 2025 at 4:11 PM
From: "Jerome Shidel via Freedos-devel" <freedos-devel@lists.sourceforge.net>
To: "FreeDOS Developers" <freedos-devel@lists.sourceforge.net>
Cc: jer...@shidel.net
Subject: Re: [Freedos-devel] XCOPY 1.7 Stack Overflow
From: "Jerome Shidel via Freedos-devel" <freedos-devel@lists.sourceforge.net>
To: "FreeDOS Developers" <freedos-devel@lists.sourceforge.net>
Cc: jer...@shidel.net
Subject: Re: [Freedos-devel] XCOPY 1.7 Stack Overflow
On Mar 21, 2025, at 10:40 AM, tom ehlert via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote:Hi Bernd,
am Freitag, 21. März 2025 um 15:05 schrieben Sie:
The index.md [1] of the repo indicates that the XCOPY 1.7 binary is built with Open Watcom.There reportedly was an issue [2] regarding stack usage with the Open Watcom built binaries.
Skimming over the source, especially [3], indicates that this may use A LOT of stack space depending on what value MAXPATH is defined to be (it is 260 for my Open Watcom installation). That is approaching 2k of stack per recursive call of xcopy_files. So the stack size will likely have to be increased to make it work with a reasonably large directory nesting level. Independent of any possible errors, the 8K mentioned in the commit may simply not be enough. Heap allocation may be considered for these quantities of memory...
I just recently stumbled upon the same issue, from the same author, in MOVE where recursion works the same.
where it "works" with a stack setting of 2K.
It works because MOVE was compiled with TC which locates the stack at the bottom, so on stack
overflow it wraps around to FFFE, where it hopefully doesn't interfere with DOS heap management.
Sort of works, but would not survive any stack checking - which Watcom C does and aborts.
should be solved by *global* source and destination path's that are managed recursively
similar to
char *origsource = source + strlen(source); // point to end of source name
...
while (find_next_dir(dir_below))
{
strcat(source, "\\");
strcat(source, "DIRBELOW");
do_stuff_for _directory_down(source)
*origsource = '\0';
}
same problem to be expected in deltree(), COPY /S, and friends.
Tom
1: https://gitlab.com/FreeDOS/base/xcopy
2: https://github.com/FDOS/xcopy/commit/1fd55f7ec29e90d87b801bc7adaa207e8ff66ba7
3: https://github.com/FDOS/xcopy/blob/03220f9bec98585802a2c25eac4ac2bd55d2b743/source/xcopy.c#L596Bernd
Ok, here is where the stack overflow occurs.
I did multiple trial runs on two different machines that boot that SD-CARD. The error occurred at the exact same directory time in every test.
I did xcopy to a blank drive and over existing files and skipped existing files. No change.
(FYI, Using XCOPY /-Y reports invalid switch -. But, it is in the help and needed to possibly override environment settings.)
I added and removed files and directories (single layer under FREEDOS\DOC\) that would be processed before getting the the overflow point. No change.
I moved the FREEDOS\DOC directly to a new location so it would not be processed before the overflow. No Change.
Put DOC in back in the proper place. No Change.
The last directory copied before the overflow was C:\FREEDOS\HELP\DE\ and all of the files in that directory got copied. The next directory should be C:\FREEDOS\HELP\DE\DOCINFO.
I deleted the DOCINFO directory. Success xcopy of the drive.
Copied the DOCINFO directory back from a backup (using xcopy). Stack overflow returned at same point.
The DOCINFO directory does not contain many files or subdirectories. Its contents are only:
../bi./bi/nls./bi/nls/help./bi/nls/help/de.bi./bi/nls/help/en.bi./bi/nls/help/es.bi./bi/nls/help/fr.bi./bi/nls/help/it.bi./bi/nls/index./bi/nls/index/de.bi./bi/nls/index/en.bi./bi/nls/index/es.bi./bi/nls/index/fr.bi./bi/nls/index/it.bi
I have used version of xcopy on my one machine with 5 DOS drives. (SD-CARD, 2 HDDs w/2 Partitions each) to copy massive amounts of files and directories without issues. Some dirs have so many children that adding a single character to the PATH will cause a PATH to long error. Making the stack overflow error very weird to me.
The DOCINFO directory is from HTMLHELP v1.0.8b. The latest version available is 1.1.0. Not sure if the error still occurs with the latest version installed. Or, if simply installing the previous version will always trigger the error.
I generally keep all released package versions (with binary differences, not those with just metadata or NLS changes) in my unofficial repository. So if someone wants or needs the 1.0.8b version, that package version can easily be found at:
:-)
Jerome
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
read-de.1st
Description: Binary data
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
