[comp.unix.i386] SCO Unix 386 3.2.0 rename

tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (07/04/90)

Just discovered a bug in the rename() library function under SCO Unix
here...  If either of the file names passed as parameters is 14
characters in length, the call fails with ENAMETOOLONG.  Seems there's
a fence-post error in there...  :-)  To work around it, use

	unlink(target);
	link(source, target);
	unlink(source);

instead of

	rename(source, target);

and you'll be OK.

-tih
-- 
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no

david@csource.oz.au (david nugent) (07/05/90)

In <955@barsoom.nhh.no> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes:

>Just discovered a bug in the rename() library function under SCO Unix
>here...  If either of the file names passed as parameters is 14
>characters in length, the call fails with ENAMETOOLONG.  Seems there's
>a fence-post error in there...  :-)  To work around it, use

>	unlink(target);
>	link(source, target);
>	unlink(source);

>instead of

>	rename(source, target);

>and you'll be OK.

Albiet with _zero_ error checking.  If the link() fails, you'll have
nothing left. :-(

It may also destroy errno if it fails; the call to unlink() might also
fail, and you'll be left with no idea what when wrong.

I use the following function under Unix's where there's no rename:

int rename (source, target)
char *source, *target;
{
	int r;
	
	(void) unlink (target);
	if (r = link (source, target))
		(void) unlink (source);
	return r;
}


david

-- 
_______________________________________________________________________________
 Unique Computing Pty Ltd  Melbourne  Australia  -  Communications Specialists 
        david@csource.oz.au    3:632/348@fidonet    28:4100/1@signet           

abs@sco.COM (Amy Snader) (07/06/90)

In article <955@barsoom.nhh.no> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes:
>Just discovered a bug in the rename() library function under SCO Unix
>here...  If either of the file names passed as parameters is 14
>characters in length, the call fails with ENAMETOOLONG.  Seems there's
>a fence-post error in there...  :-)  
>Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
>tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no

Actually, the bug isn't a fence-post error, but rather
an example of another classic software failure mode, the feature
collision :-).  That is, two features that worked when tested separately 
failed when combined. 
In this case, the two features are rename() and
the POSIX "feature" that names > 14 characters should cause the error
ENAMETOOLONG to be returned rather than causing the names to be truncated. 

By setting the kernel variable ETRUNC to 1 using the link kit, 
linking a new kernel, and rebooting using the new kernel, 
you can disable the POSIX "feature". 
This will cure the feature collision, and  
rename() will work on 14 character filenames. 
The resulting kernel won't be POSIX-compliant, so
if you are part of an organization that demands POSIX compliance,
this workaround is not recommended. 
On the other hand, many people find the non-POSIX behavior more
satisfactory anyway, as it is how Xenix (and many other *ixes)
have always behaved.

Thanks for bringing this to our attention, Tom.   
This bug now occupies a place of honor on the list of things to
fix.
	--Amy {uunet|amdcad|microsoft}!sco!abs