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