The free forums are no longer in use. It remains available as read-only archive.
Log In
Home
9:14 am
September 26, 2010
Offline
It could be that the exec function is not enabled, try extracting the backup archive manually and then restart the restore process with the "skip files restore" option checked.
Ovidiu
8:39 pm
December 14, 2011
Offline
Hi,
I have exactly the same problem.
It looks like that the tar file is not created in a correct way.
So Xcloner has created the tar file by omitting the last char for several files.
I see it for *.jpg files (which will become *.jp) and for png fiiles (which will become *.pn) as well.
It happens not for all files. Like the initiator of this thread I do see:
9 "bad" image files in administrator\components\com_xcloner-backuprestore\css\start\images which ends with "*.pn" instead of "*.png".
So the problem is not by the restore but by the creation of the tar file.
I am running php 5.3.2 with joomla 1.5.25. I think it is running on FreeBSD 8.1
Jacky
7:28 am
December 14, 2011
Offline
Made some additional checks and tests:
The bad files are (not the only once):
administrator\components\com_xcloner-backuprestore\css\start\images\ui-bg*
Info: The other files in that directory are created with the correct extension in the tar file.
Made some tests with modified settings:
Server Use Options: Activate "tar" > does not work on my side.
System > Backup Manual Process > Time between requests > 10
> same issue
System > Backup Manual Process > Time between requests > 30 and
System > Backup Manual Process > Files to process per requests > 10
> same issue
Everytime the same files got a corrupted name.
Other files which got renamed in the created tar file:
koenigsschiessen_1_20100924_1781736170.jp instead of koenigsschiessen_1_20100924_1781736170.jpg
The above file is located at three diferent positions on the filesystem and it got corrupted on all three locations in the tar file.
Other examples:
koenigsschiessen_10_20100924_1234918375.jp instead of koenigsschiessen_10_20100924_1234918375.jpg
kroeningsballllll_1_20100926_1866995359.jp instead of kroeningsballllll_1_20100926_1866995359.jpg
Hm, I cannot see what all the files with the corrupt extensions have in common which might give a hint on that bad behaviour.
Jacky
12:52 pm
September 26, 2010
Offline
Hi Jacky, can you send me a download link to the backup you have there through our contact form here to see if the files are properly written in the archive?
Thanks, Ovidiu
5:01 pm
December 14, 2011
Offline
Hi,
I sent you a link with a screenshot.
I made another test by only backup the administrator directory to reduce the amount of data.
But the same issue occures with the same files.
I see the issue with the following extensions:
png > pn
jpg > jp
ini > in
php > ph
xml > xm
Round about 0.3% of the files are affected.
Jacky
11:26 am
September 26, 2010
Offline
Hi Jacky, unfortunately the issue seems to be with your hosting enviroment(combined with some code from XCloner) as we tried to duplicate this issue here with no luck, if by any chance you could give us a testing account access to your host, so we can directly debug XCloner, we could probably be of better help.
Regards, Ovidiu
10:01 pm
December 14, 2011
Offline
Hi,
Yes, I agree. it looks like an issue in combination of OS, Joomla, XCloner.
For security reasons I cannot let you on our system.
But maybe can can tell me in which file and how I should enable the tracing. And where I can find the output file.
I think I will not be a problem to send you the logs.
I tried it to set "$debug=1" for fileRecursion.php but ether that one is not in use during the creation of the backup or I didn't see the logfile (or searched for it on a wrong location).
Jacky
11:32 am
September 26, 2010
Offline
There is a debug option in the XCloner Config->System tab, a debug file will be generated in the administrator/backups/ directory. However the file writing to the archive is handled by the TAR.php library inside the xcloner restore/ folder, and that needs to be debuged separately.
Ovidiu
1:26 pm
December 14, 2011
Offline
Hi,
1. Step: xcloner.log (found in administrator/backups)
It looks fine from my perspective, the extensions of the ui-* files are listed correctly.
...
1454. directory - administrator/components/com_xcloner-backupandrestore/css
1455. file - administrator/components/com_xcloner-backupandrestore/css/main.css
1456. directory - administrator/components/com_xcloner-backupandrestore/css/start
1457. directory - administrator/components/com_xcloner-backupandrestore/css/start/images
1458. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_glass_45_0078ae_1x400.png
1459. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_flat_55_999999_40x100.png
1460. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_f7a50d_256x240.png
1461. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_gloss-wave_50_6eac2c_500x100.png
1462. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_056b93_256x240.png
1463. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_d8e7f3_256x240.png
1464. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_inset-hard_100_fcfdfd_1x100.png
1465. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_fcd113_256x240.png
1466. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_e0fdff_256x240.png
1467. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_f5e175_256x240.png
1468. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_glass_55_f8da4e_1x400.png
1469. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_glass_75_79c9ec_1x400.png
1470. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_0078ae_256x240.png
1471. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_gloss-wave_45_e14f1c_500x100.png
1472. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_gloss-wave_75_2191c0_500x100.png
1473. file - administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_flat_75_aaaaaa_40x100.png
1474. file - administrator/components/com_xcloner-backupandrestore/css/start/jquery-ui-1.8.9.custom.css
1475. file - administrator/components/com_xcloner-backupandrestore/css/dtree.css
...
Next step: check TAR.php.
to be continued ...
10:07 pm
December 14, 2011
Offline
Hi,
I made some further tests. The problem occures with filenames > 99 characters.
If the filenames is > 99 then then TAR.php uses the function _writeLongHeader.
I have the feeling that the last char of the filename is not written correctly to the block.
I made a test and modified TAR.php:
function _writeLongHeader($p_filename)
{
# Original: $v_size = sprintf("%11s ", DecOct(strlen($p_filename)));
$v_size = sprintf("%11s ", DecOct((strlen($p_filename) + 1 )));
$v_typeflag = 'L';
...
It looks like that it works with that modification. But I have to make some additional tests.
But one thing is for sure: the problme occures when the used path including the filename is larger than 99.
In my example:
administrator/components/com_xcloner-backupandrestore/css/start/images/ui-bg_glass_45_0078ae_1x400.png
which is 102 characters long while an other image in the same directory like:
administrator/components/com_xcloner-backupandrestore/css/start/images/ui-icons_f7a50d_256x240.png
works (which is 98 characters long).
I think there is a "PEAR" module in use. Maybe this one has a bug.
Jacky
All RSS1 Guest(s)
