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