Pbackup 3.1.9-1
What about using this crap in another distro?
There has been some rquests of this lately, and I'm doing some loud thinking here. At this stage this is not much tested. - I'm just too happy with my Puppy. I have ran it in ubuntu and grafpup. First of all you must match the dependecies. Then you are ready for a linux system with roots rights. But most common, you run another distro as user, and you have limited rights. Now it depends on how strickly the users permissions are set. In grafpup it seems ok. In ubuntu user are not allowed to kill a process it has started. This will not close the box that shows progress during backup. User that are not allowed to delete files in /tmp/ which makes Pbackup leave its trashfiles. User maybe doesn't have rights to set a scheduled backup in /var/spool/cron/crontabs/$USER. In some multiuser system user should set this tasks in /etc/crontabs/. At last Pbackup can't start cron by default at boot in a system that need superuser rights to start services at boot.
1-2-3-GO
1. Copy Pbackup directory somewhere in your system. Helpfile(s) goes to /usr/share/doc/pbackup/.
2. Make link /usr/bin/gtkdialog3 to whereever gtkdialog was installed.
3. If user aren't owner of Pbackup files, the progress box won't be deleted after backup. To change owner of files:
Example: chown james -R /usr/local/pbackup
GO. (Scheduling must be set manually.)
Do you strugle to get it work, please share your effort to help your friends.
Requirements:
- bash, busybox (or similar)
- gtkdialog 0.7.15, xdialog
Optional:
- cdrtools (mkisofs, cdrecord) for CD-burning
- dvd+rwtools (growisofs) for DVD-burning
- curl for transferring via FTP
- cron for scheduling
All these are Puppy builtin
Sigmund
There has been some rquests of this lately, and I'm doing some loud thinking here. At this stage this is not much tested. - I'm just too happy with my Puppy. I have ran it in ubuntu and grafpup. First of all you must match the dependecies. Then you are ready for a linux system with roots rights. But most common, you run another distro as user, and you have limited rights. Now it depends on how strickly the users permissions are set. In grafpup it seems ok. In ubuntu user are not allowed to kill a process it has started. This will not close the box that shows progress during backup. User that are not allowed to delete files in /tmp/ which makes Pbackup leave its trashfiles. User maybe doesn't have rights to set a scheduled backup in /var/spool/cron/crontabs/$USER. In some multiuser system user should set this tasks in /etc/crontabs/. At last Pbackup can't start cron by default at boot in a system that need superuser rights to start services at boot.
1-2-3-GO
1. Copy Pbackup directory somewhere in your system. Helpfile(s) goes to /usr/share/doc/pbackup/.
2. Make link /usr/bin/gtkdialog3 to whereever gtkdialog was installed.
3. If user aren't owner of Pbackup files, the progress box won't be deleted after backup. To change owner of files:
Example: chown james -R /usr/local/pbackup
GO. (Scheduling must be set manually.)
Do you strugle to get it work, please share your effort to help your friends.
Requirements:
- bash, busybox (or similar)
- gtkdialog 0.7.15, xdialog
Optional:
- cdrtools (mkisofs, cdrecord) for CD-burning
- dvd+rwtools (growisofs) for DVD-burning
- curl for transferring via FTP
- cron for scheduling
All these are Puppy builtin
Sigmund
Sigmund
Haven't been here for a while but I've just had an unhappy experience with Pbackup. I hope this has not already been reported, I've searched and can't find anything.
My daily incremental backup includes my 'data disk' which is a vfat partition from Windows days. It is 4.9Gb. Quite by accident I discovered a directory and contents not being backed-up. The files in this directory are normally updated by a Windows XP program. As the files are only text files I made a small update to one from Puppy, at the next backup it got backed-up.
I know I should not be using a Windows program but I use it for making dvds of my photos and having only returned 3 weeks ago from visiting your part of the world I've a LOT of photos to work with and a familiar program is appreciated, I don't do this sort of thing very often.
Anyway, is there any reason you know of why Pbackup wouldn't pick up a Windows update? The change dates are quite OK. I'll post all the config files etc. if you need some more info.
Cheers
Geoff
PS I still like your Pbackup, I won't kick it too hard.
Haven't been here for a while but I've just had an unhappy experience with Pbackup. I hope this has not already been reported, I've searched and can't find anything.
My daily incremental backup includes my 'data disk' which is a vfat partition from Windows days. It is 4.9Gb. Quite by accident I discovered a directory and contents not being backed-up. The files in this directory are normally updated by a Windows XP program. As the files are only text files I made a small update to one from Puppy, at the next backup it got backed-up.
I know I should not be using a Windows program but I use it for making dvds of my photos and having only returned 3 weeks ago from visiting your part of the world I've a LOT of photos to work with and a familiar program is appreciated, I don't do this sort of thing very often.
Anyway, is there any reason you know of why Pbackup wouldn't pick up a Windows update? The change dates are quite OK. I'll post all the config files etc. if you need some more info.
Cheers
Geoff
PS I still like your Pbackup, I won't kick it too hard.
Good to see you around
About your problem:
Could it so easy that the date-setting in windows differs from Puppy? Or do we have yet another issue because FAT and EXT uses different attributes, and therefor are hard to compare? In 'sync' these are more obvious, and it has got a option to eliminate the problem.
Could you experiment with 'find -ctime' to see if you can see if it detects date correct (-ctime is checked by 'backup' to see if it is newer than last backup). If you change a file in windows, and then goes to puppy to see if it was changed today...
Sigmund
Hello... If it's good, of course you should. We should always use what's best. That's why I use Puppy, but who knows tomorrow...I know I should not be using a Windows program
About your problem:
Could it so easy that the date-setting in windows differs from Puppy? Or do we have yet another issue because FAT and EXT uses different attributes, and therefor are hard to compare? In 'sync' these are more obvious, and it has got a option to eliminate the problem.
Could you experiment with 'find -ctime' to see if you can see if it detects date correct (-ctime is checked by 'backup' to see if it is newer than last backup). If you change a file in windows, and then goes to puppy to see if it was changed today...
Sigmund
Sigmund-
Yes, this IS one of those problems with Windows & Linux & date/times.
When Windows reports 'Date last Modified' is it using ctime or mtime?
When ROX reports 'Date Last Modified' is it using ctime or mtime?
I modified a file in Windows and the 'Date Last Modified' was correctly reported in Windows. I booted Puppy and ROX shows the 'Date Last Modified' as 10 hours into the FUTURE. Modify a file in Puppy and 'Date Last Modified' is correct in Puppy and (I think) in Windows. I haven't checked in Windows but I'm fairly certain I'd have noticed a discrepancy. As I do most of this in the late afternoon and evening a 10 hour discrepancy would be rather obvious.
mtime -1 finds the file that I modified in Windows
ctime -1 does NOT find the file I modified in Windows.
I'm finding this rather confusing
Does your script use mtime or ctime or both?
I can't think of any easy way to 'play' with this other than by booting Windows and then Puppy. Using VirtualBox or the network I'd not be sure which was doing the actual updating and be more confused than ever . Using the 2 systems I always think of something I should have checked AFTER I've changed systems
I'll keep thinking.
Cheers
Geoff
Yes, this IS one of those problems with Windows & Linux & date/times.
When Windows reports 'Date last Modified' is it using ctime or mtime?
When ROX reports 'Date Last Modified' is it using ctime or mtime?
I modified a file in Windows and the 'Date Last Modified' was correctly reported in Windows. I booted Puppy and ROX shows the 'Date Last Modified' as 10 hours into the FUTURE. Modify a file in Puppy and 'Date Last Modified' is correct in Puppy and (I think) in Windows. I haven't checked in Windows but I'm fairly certain I'd have noticed a discrepancy. As I do most of this in the late afternoon and evening a 10 hour discrepancy would be rather obvious.
mtime -1 finds the file that I modified in Windows
ctime -1 does NOT find the file I modified in Windows.
I'm finding this rather confusing
Does your script use mtime or ctime or both?
I can't think of any easy way to 'play' with this other than by booting Windows and then Puppy. Using VirtualBox or the network I'd not be sure which was doing the actual updating and be more confused than ever . Using the 2 systems I always think of something I should have checked AFTER I've changed systems
I'll keep thinking.
Cheers
Geoff
Sigmund
Thanks for reply and 'work'
Don't know your code but would it be possible to use both. Make all tests in the form 'if (ctime > date OR mtime > date) then backup-the-file'?
It appears to me that if either has been changed there is good reason to backup the file, 'backup' can't know why they have changed.
May make the backup file a bit bigger however, to me, that is a 'good' fault.
Cheers
Geoff
Thanks for reply and 'work'
Don't know your code but would it be possible to use both. Make all tests in the form 'if (ctime > date OR mtime > date) then backup-the-file'?
It appears to me that if either has been changed there is good reason to backup the file, 'backup' can't know why they have changed.
May make the backup file a bit bigger however, to me, that is a 'good' fault.
Cheers
Geoff
Version 3.0.1
Changelog:
- Refined function to select files/dirs to include/exclude.
- Japanese translation. Thanks to Jimmy Lu (nyu).
- Changed 'find'-syntax from -ctime to -mtime. More compatible with other filesystems (thanks to Geoffs)
- External cron-editor is changed from gcrontab to Pschedule.
- Got rid of some messages to terminal when running quiet mode.
- Moved crond from /etc/rc.d/rc.local to $HOME/.xinitrc to coexist with Pscedule and Pdrive_deamon.
- Bugfix: Radiobutton to select 'schedule weekly' missed time in description.
- Bugfix: Be sure item in crontabs is owned by Pbackup before spesify schedule.
- Minor code cleanup.
Download from main post
Sigmund
Changelog:
- Refined function to select files/dirs to include/exclude.
- Japanese translation. Thanks to Jimmy Lu (nyu).
- Changed 'find'-syntax from -ctime to -mtime. More compatible with other filesystems (thanks to Geoffs)
- External cron-editor is changed from gcrontab to Pschedule.
- Got rid of some messages to terminal when running quiet mode.
- Moved crond from /etc/rc.d/rc.local to $HOME/.xinitrc to coexist with Pscedule and Pdrive_deamon.
- Bugfix: Radiobutton to select 'schedule weekly' missed time in description.
- Bugfix: Be sure item in crontabs is owned by Pbackup before spesify schedule.
- Minor code cleanup.
Download from main post
Sigmund
Version 3.0.2
Changelog
- Improved code for setting html-viewer (Thanks to Dougal)
- Moved translators and contributers to 'about'
- Autoselect button in dialogs.
- Pbackup enviroment variables is put first in /usr/local/pbackup.
- Crond is now autostarted from ~/Startup, instead of ~/.xinitrc.
- Bugfix: accept symlinks to dir for choosing temporary storage.
- Bugfix: remove item from 'save-from' doesn't accept spaces in filename.
- Bugfix: symlink to dir is not accepted by 'sync' function
- Bugfix: restore file from CD/DVD.
- Bugfix: resore all in backup.
Download from main post
Sigmund
Changelog
- Improved code for setting html-viewer (Thanks to Dougal)
- Moved translators and contributers to 'about'
- Autoselect button in dialogs.
- Pbackup enviroment variables is put first in /usr/local/pbackup.
- Crond is now autostarted from ~/Startup, instead of ~/.xinitrc.
- Bugfix: accept symlinks to dir for choosing temporary storage.
- Bugfix: remove item from 'save-from' doesn't accept spaces in filename.
- Bugfix: symlink to dir is not accepted by 'sync' function
- Bugfix: restore file from CD/DVD.
- Bugfix: resore all in backup.
Download from main post
Sigmund
Try running and you'll see an error generated because of the & in pbackup.desktop
It should really be replaced by, although it doesn't seem to actually break anything...
Code: Select all
jwm -p
It should really be replaced by
Code: Select all
&
Yes, I'm an idiot.
My /usr/share/applications/pbackup.desktop:
My /usr/share/applications/pbackup.desktop:
Code: Select all
[Desktop Entry]
Encoding=UTF-8
Name=Pbackup backup to CD/DVD/HD
Icon=mini-diskette.xpm
Comment=Pbackup backup to CD/DVD/HD
Exec=pbackup
Terminal=false
Type=Application
Categories=Archiving
GenericName=Pbackup
Sorry for not being clear enough - what you posted is fine, but it doesn't match what is in the .pet - unless somehow I've got an old .pet labelled as 3.03
Last edited by disciple on Mon 03 Mar 2008, 08:40, edited 1 time in total.