As an anti-virus procedure all root-entries on floppy are filled with zero byte
files. User starts batchfile which checks if the disk is valid and if so does
the following:

ren pca2.exe pca.exe
ren check.com check.old

This works in MS-DOS, but gives two "rename: Too many open files" in FreeDOS. If
one root-entry is deleted, than the ren command works. It seems therefor that
the ren command first does a copy and then a delete? MS-DOS however does a
rename in the root-entry and nothing more.

Have you tried this with FreeCOM 0.84pre? Get it at fdos.org/kernel in the
development section (the link is "command.com").

(In reply to comment #1)
> Have you tried this with FreeCOM 0.84pre? Get it at fdos.org/kernel in the
> development section (the link is "command.com").

I've just downloaded this version with filedate 11th october 2005. This version
has the same problem.

Messing up for a person working at a Dutch computer magazine isn't that good
promotion for FreeDOS. Problem is we have no official maintainer for FreeCOM.

any testprogram available? I don't have a "pca.exe" and not planning on buying a
PC Active magazine for it.

perhaps sourcecode for REN will show more.
www.fdos.org/kernel contains latest sources for FreeCOM

(In reply to comment #3)
> Messing up for a person working at a Dutch computer magazine isn't that good
> promotion for FreeDOS. Problem is we have no official maintainer for FreeCOM.

Ssst...

I usually don't mention that I'm working for a Dutch computer magazine. It
should not matter for the problem at hand :)

> any testprogram available? I don't have a "pca.exe" and not planning on buying a
> PC Active magazine for it.

That's not nescessary. If wanted I can give a downloadlink to one of the
diskimages with this problem. However you vcan also make your own testcase. Just
fill up the root entry of a disk with filenames (about 128?). Then try the ren
command and you've reproduced the bug. Or better an incompatibility betweeen
FreeDOS and MS-DOS.

> perhaps sourcecode for REN will show more.
> www.fdos.org/kernel contains latest sources for FreeCOM

Probably. But I'm terrible with C, so hopefully someone else will pick this up.

This might be a bug in KERNEL rather than in FREECOM.
Your problem is that renaming needs a free directory
entry in FreeDOS while it does not in MS DOS.

Changing summary from
ren behaves different then its MS-DOS counterpart
to
ren does not work in full root directory

Possible solution would be to change dos_rename
(which always gets truename strings as input)
to work without allocating a new slot in

  ret = alloc_find_free(fnp2, path2, fcbname);

if it detects that old and new name are in the
same directory and can therefore be handled
without making a new directory entry.

The exact implementation might be a bit complicated,
so I hope some kernel expert will read this :-).

Created an attachment (id=43) [details]
a suggested patch to make same dir rename work without using a temp dir entry

This patch should make "rename" work without using a
temporary directory entry, so you should be able to
rename even when the (root) directory is full.

Note: rename still does not take care to fix the ".."
entry when you use the int21 interface to rename a
directory (no problem for files) in a way which makes
the directory "change parents".