Path: utzoo!attcan!uunet!sco!abs
From: abs@sco.COM (Amy Snader)
Newsgroups: comp.unix.i386
Subject: Re: SCO Unix 386 3.2.0 rename() fails on 14 char file names!
Message-ID: <7014@scolex.sco.COM>
Date: 5 Jul 90 22:00:40 GMT
References: <955@barsoom.nhh.no>
Sender: news@sco.COM
Reply-To: abs@sco.COM (Amy Snader)
Distribution: comp
Organization: The Santa Cruz Operation, Inc.
Lines: 33


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