Angelo,
You might look at "Back in time"
https://backintime.readthedocs.io/en/latest/mainwindow.html This is a
Python script that uses rsync as the backup mechanism but has GUI front
end to allow configuration. The only caveat is that it does not seem to
work with NTFS file systems. I form
Your experience with udev matches mine. I'm not sure if it's just a really
complex process, or if it doesn't actually work the way it says it works,
but it seems that using it successfully rarely takes fewer than 19
attempts. And I don't believe that ``--reload`` works at all; I always
reboot to tr
Hi,
although I did a lot of tests with many engagement I was not able to catch
the UDEV event
Having exhausted my trust ... I give up.
I will not try bacula which (perhaps) is excessive for my purposes, and so
I'll try with a simple script that uses the rsynk utility to copy the only
file
You should be using the UUID of the partition to detect and mount your
target. Detecting the "whole" drive is immaterial, since you want udev to
mount a partition, not a drive.
I would try to get one partition working first, then proceed to the others.
With udev testing, I've always had far more l
HI Seth,
I'm sorry to still bother you ..., but your help could save me a lot of
useless tests (since there are many parameters to manage and knowing what I
really have to do could, this trigger me the use of useless ones).
I think that I understood the crux of the problem ... (the UDEV theory …
On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote:
> Using the UUID is correct.
>
> If the script isn't being executed by udev but you can confirm that
> udev is correctl mounting your target partition, and the shell script
> functions as expected when you run it manually, then I would c
Using the UUID is correct.
If the script isn't being executed by udev but you can confirm that
udev is correctl mounting your target partition, and the shell script
functions as expected when you run it manually, then I would create a
simple timestamp shell script just to confirm that you can get
thank you Seth,
I have no problems with the script executed at the UDEV event (if this is
the meaning you attribute to the term ).
I've already done this script that works, if run from a terminal.
If by the term you mean something different, please tell me.
The problem is that this script is no
Angelo,
I agree with Tom's analysis, but my udev script accounts for it by
mounting your drive with a very specific designator.
Here is how I have tested this sort of thing before:
0. Get the UUID of your drive with blkid
1. Write a udev script to detect your drive by UUID when attached, and
to e
Hi Seth,
after reading the answer from Tom, (the duration of the tread) I am no
longer sure that a scrpt acting at the event to connect an HD USB to the
computer to back up the data may be the best solution for me .
I'm dealing with the problem of backing up data on my computer for a long
time.
I
Thank you Tom,
OK,I hadn't consider, at the moment, the threat duration aspect,.
The script (to execute for the UDEV 'event) cannot be affected by this kind
on problem because it have only to write a small file, his content is :
This script carries out its task when performed from the command l
That tecmint article has several serious issues with it (this is
reflected in the comments, too).
You need a slightly more complex script for what you are attempting.
This is based on Attachup, a pyudev srcipt that backs-up a thumbdrive
to a computer upon attaching it - but you can make your shell
In general I have no ideas, but I do know that scripts executed
in udev rules have to run "fast", or they are automatically
killed off. You might want to consider having the script
do something like:
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/full/path/to/do-the-backup/script
HERE
That will ve
I use crontab to run an rsync command...
On 6/30/19 8:38 AM, Angelo Moreschini wrote:
Hi,
in order to backing up data when I connect to computer an USB HD, I
wrote the follow UDEV rule :
--
SUBSYSTEM=="block", ACTION=="add", ATTRS
On Fri, Nov 07, 2014 at 03:20:20PM -0500, Kevin Cummings wrote:
> On 11/06/2014 06:53 PM, Tom Horsley wrote:
> > On Thu, 6 Nov 2014 18:47:23 -0500
> > Fred Smith wrote:
> >
> >> not finding anything on that, I hit on writing a udev rule for the
> >> USB device to make sure it appeared as a predict
On 11/06/2014 06:53 PM, Tom Horsley wrote:
> On Thu, 6 Nov 2014 18:47:23 -0500
> Fred Smith wrote:
>
>> not finding anything on that, I hit on writing a udev rule for the
>> USB device to make sure it appeared as a predictable /dev/video.
Did you try looking in /dev/v4l? My laptop builtin webcam
On Thu, 6 Nov 2014 18:47:23 -0500
Fred Smith wrote:
> not finding anything on that, I hit on writing a udev rule for the
> USB device to make sure it appeared as a predictable /dev/video.
I did something similar to recognize my 3D printer when I plug it
in, and it was quite challenging to make al
On 01/23/2011 03:46 AM, Tom Horsley wrote:
> On Sat, 22 Jan 2011 17:01:00 -0500
> slamp slamp wrote:
>
>> did anything change on how udev creates devices for usb's?
>> specifically debugging device for adb?
> I thought they had been eradicating all the google android
> patches in the kernel and wot
On Sat, Jan 22, 2011 at 5:16 PM, Tom Horsley wrote:
> On Sat, 22 Jan 2011 17:01:00 -0500
> slamp slamp wrote:
>
>> did anything change on how udev creates devices for usb's?
>> specifically debugging device for adb?
>
> I thought they had been eradicating all the google android
> patches in the ke
On Sat, 22 Jan 2011 17:01:00 -0500
slamp slamp wrote:
> did anything change on how udev creates devices for usb's?
> specifically debugging device for adb?
I thought they had been eradicating all the google android
patches in the kernel and wot not because google won't
wiggle the rubber chicken t
20 matches
Mail list logo
