EXTEND.pm
fails to move directories across filesystems.
Dreamhost web hosting has a setup in which /tmp and home directories are on separate filesystems. EXTEND.pm doesn't cope with this, failing when asked to move the directory - having looked at the code for
CPAN:File::Copy, the first Perl
rename
call will fail, and then it will try to do a
copy
on the directory.
Quite a bit more analysis at
TWiki:Support.InstallingPluginsDreamhostErrors - I think this can be fixed by doing code somewhat like
CPAN:File::Copy::Recursive, or just using that module.
This could also occur in non-hosting setups, e.g. a large filesystem for TWiki data directory and smaller one for all the others.
--
TWiki:Main/RichardDonkin - 11 Mar 2007
Yes. It's common to have the data and pub dirs on a different filesystem to the code.
I'd be quite happy to use
CPAN:File::Copy::Recursive, but there will be people who don't want the additional excise of another CPAN module
--
TWiki:Main.CrawfordCurrie - 12 Mar 2007
Agree about the extra CPAN module, since not part of Perl core, but how about doing something similar? File::Copy::Recursive also preserves the permissions, which I thought was the point of doing a tgz install.
Alternatively, does the Archive::Tar code let you do a partial extract, in which case we could maybe extract in place e.g. pub hierarchy to one FS, then data hierarchy to another one? This would also preserve permissions using tgz installs.
--
TWiki:Main.RichardDonkin - 12 Mar 2007
Actually I think it's best to just use the File::Copy::Recursive module - installing extensions from Configure is a nice feature, but someone who can't install this module or has Internet problems can just install the extension manually.
--
TWiki:Main.RichardDonkin - 12 Mar 2007
If File::Copy::Recursive is not part of standard Perl then we should NOT add this dependency for this little problem. Each time we add another silly unneccessary dependency we make it more difficult for newbies to installl TWiki. We go through this discussion over and over again. This problem can for sure be solved without needed another CPAN lib. There are many people that cannot install CPAN libs. When you are behind an authenticated firewall both running CPAN, yum, apt-get, rpm etc etc can be a challenge. Then you have to manually download the lib, copy it to the server and build it. It is not trivial. We are talking about making TWiki easier to install all the time. And still these proposals come back again and again adding CPAN dependencies for a program you use to install and configure TWiki. A task where performance and speed does not matter and a task typically performed by a newbie twiki admin.
--
TWiki:Main.KennethLavrsen - 13 Apr 2007
I don't understand this; I already break the dirs down, and do a File::Copy::move at the leaf file level only, so no recursive copy is required. Also, File::Copy::move is supposed to fall back to a cp-rm sequence if it fails to rename.
Can you please provide a testcase? I can't reproduce any problem with this.
CC
All I have is the information at
TWiki:Support.InstallingPluginsDreamhostErrors. However, the extension installer does appear to be trying to rename directories, and of course
cp
of a directory will fail too (it doesn't do recursiveness). The key error message from that page is
Error: Failed to move file 'pub/TWiki/CalendarPlugin/' to /home/bluespirit/beckstromwiki.com/twiki/pub/TWiki/CalendarPlugin/: Is a directory
.
I would expect that installing CalendarPlugin on a box where /tmp is a RAM based filesystem would trigger this bug.
--
TWiki:Main.RichardDonkin - 16 Apr 2007
The "Failed to move file" error currently shows up with many plugins (of ~40 plugins I tried to install recently, only ~5 were able to install succesfully with
configure
). This is on a standard Debian system (with
/tmp
and
../twiki
in separate filesystems).
Reported also in
Item3891.
For testing purposes: An easy way to create a "new filesystem" is with the "--bind" option to mount:
In
/etc/fstab
:
/old/location/ /new/bind/location/ none bind 0 0
--
TWiki:Main.SteffenPoulsen - 17 Apr 2007
See also:
Item3891 for another manifestation of the same problem.
CC
OK, it was because there was no check for the source being a directory, which on occasion it is.
CC