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.

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.

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...

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-
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

Pbackup uses only -ctime, which seems to the wrong choice. -mtime returns status of inode, while -ctime return filestatus. I don't see any bad sides of changing to -mtime, but I have to do some testing before we get a bugfix release.

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

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.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum