Build Farm temporary name issue

Green, Paul Paul.Green at stratus.com
Fri May 30 16:20:49 GMT 2008


The build farm procedure "s4selftest_update" uses a rather roundabout
method to copy the directory named "s4selftest" into (e.g.)
"s4selftest.samba_3_2_test.gcc":

s4selftest_update() {
        lock_file "s4selftest.lck" || {
                return 1;
        }

        copy_dir $s4selftest $s4selftest.$tree.$compiler.$$ || {
                rm -rf $s4selftest.$tree.$compiler.$$;
                unlock_file "s4selftest.lck";
                return 1;
        }

        rm -rf $s4selftest.$tree.$compiler
        mv $s4selftest.$tree.$compiler.$$ $s4selftest.$tree.$compiler

        unlock_file "s4selftest.lck"
}

It first copies the s4selftest subdirectory into a temporary,
uniquely-named subdirectory, deletes the old target directory, then
renames the temporary, uniquely-named subdirectory into the final target
directory.

This fails on host m104 because the directory name that is generated for
the temporary directory is too long; while we now support 255-character
file names, VOS still limits directory names to 32 characters. The
generated name is 39 characters long.

I see two potential solutions.

(A) Do the operations in a different order that eliminates the need for
the temporary directory.

(B) Shorten the name of the temporary directory, for example,
"$s4selftest.$$".

I wanted to raise this issue and get a better understanding of the
purpose of the existing logic before rushing in to change it.  Can
someone explain what's going on here?

The least-disruptive change would seem to be choice (B).  Is that OK
with people?

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen



More information about the samba-technical mailing list