Andy Smith <andy@strugglers.net> writes:

Hi,

On Sun, May 18, 2025 at 12:47:25PM -0400, Default User wrote:

Since I know almost no shell scripting, the rsync usb drive A�
to usb drive B copy is done with a simple bash script consisting
only of the rsync backup command, with options and parameters, but
without any code to verify that usb drive B is attached.

I really should learn more shell scripting. That is something
else I will get to "Real Soon Now".
:)

If your backup script is a bash script then all you need do is put
something like:

if ! findmnt /mnt/usb-drive-b; then
echo "Mount USB drive B before running this!" >&2
exit 1
fi

why not
if ! mountpoint /mnt/usb-drive-b ; then ...
?

KJ
--
http://wolnelektury.pl/wesprzyj/teraz/
EMACS = Even a Master of Arts Comes Simpler

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue May 20, 2025 at 6:41 AM BST, Kamil Jońca wrote:

why not
if ! mountpoint /mnt/usb-drive-b ; then ...
?

I'd not heard of either `mountpoint` or `findmnt` before. I see they're
both part of util-linux, so I guess as likely as each other to be
available (which is one criterion I would use for choosing)

The approach I would have used (and it's not infallible) is

test -f /mnt/usb-drive-b/.some-file

where '.some-file' exists on the device but not on the empty mount
point.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 20, 2025 at 09:30:37AM -0400, Lee wrote:

On Tue, May 20, 2025 at 6:00 AM Jonathan Dowland wrote:

On Tue May 20, 2025 at 6:41 AM BST, Kamil Jońca wrote:

why not
if ! mountpoint /mnt/usb-drive-b ; then ...
?

I'd not heard of either `mountpoint` or `findmnt` before. I see they're both part of util-linux, so I guess as likely as each other to be
available (which is one criterion I would use for choosing)

The approach I would have used (and it's not infallible) is

test -f /mnt/usb-drive-b/.some-file

where '.some-file' exists on the device but not on the empty mount
point.

If we're continuing this thread, why would one want to use
/mnt/usb-drive-b for mounting a usb drive instead of automatically
mounting to
/media/$USER/filesystem-UUID ?

What do you do if you get two USBs containing file systems with
the same UUID?

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaCyEvwAKCRAFyCz1etHa RpKUAJ0d/NyjXd013KKsPFYaasfE8BpLUQCfXQUIzI4J1j6k/xmtMa5FxhzzTvg=
=Wtsq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 20, 2025 at 09:45:11AM -0400, Lee wrote:

On Tue, May 20, 2025 at 9:33 AM wrote:

[...]

What do you do if you get two USBs containing file systems with
the same UUID?

Is that possible? I suppose it is.. so I'd go looking for how to
change the UUID for one of the usb drives.

If you copy a whole file system (e.g. with dd), the UUID will
travel with it. It's just data, after all. Sometimes you want it,
sometimes not.

If you then modify one file system's content, you'll get two
file systems with the same UUID and... with different data =:-o

The horrors :)

Remember: the second "U" in "UUID" is a lie ;-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaCyM1wAKCRAFyCz1etHa RuhxAJ9dQNNX1KDyAKaUAR8gXm8qAe4jPwCeJVM+TQUAwkFggVW/IfqLRagJtVQ=
=AWd8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On May 20, 2025, Lee wrote:

On Tue, May 20, 2025 at 6:00 AM Jonathan Dowland wrote:

On Tue May 20, 2025 at 6:41 AM BST, Kamil Jońca wrote:

why not
if ! mountpoint /mnt/usb-drive-b ; then ...
?

I'd not heard of either `mountpoint` or `findmnt` before. I see they're both part of util-linux, so I guess as likely as each other to be
available (which is one criterion I would use for choosing)

The approach I would have used (and it's not infallible) is

test -f /mnt/usb-drive-b/.some-file

where '.some-file' exists on the device but not on the empty mount
point.

If we're continuing this thread, why would one want to use
/mnt/usb-drive-b for mounting a usb drive instead of automatically
mounting to
/media/$USER/filesystem-UUID ?

I used /mnt/backup because I only wanted the partition mounted while the
backup was running (it was one of several on that physical drive). The
backup script did the mount/rsync/unmount as part of the execution.
Really, the only point of this was a "well, I can't accidentally delete
it if it's not mounted" train of thought.

Now, the daily driver backs up to an old desktop (that I rarely interact
with "directly"), so I'm less concerned about the chances of accidental deletion -- even if I do manage to delete the backups entirely, the
originals are still on the PC (and monthly exports out of the house
anyway).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmgslsUACgkQbWVw5Uzn KGAqkQ//em3epBmzjKLQFbP0jZ8qh2fwZnkSVJcAvknrrHdETalvRGVWaSGM8NPv N/I2Bm8pfjwvcgIh7arvgvICI4JqVcItY0h29ZggT5ZW8Qul2ExVO68dDXUKhiu9 5tcGnuusTzLmNHMGtHM4h6VWRGWRIKSiL9JI0e97GvllEsOe9SECtW01cMjRrY/z ai6M+tVmxLxwTrWhGnjS9z1b5/xjzp5m7jnGI8aQac5eo67QMOxIZ+oPMV1A5znU WrQWmgSwPeWGuEod3qBRik0uYTN22JYi5lxnP1KGKrYQHRbCw6tEGUNcBO3D6V88 BlZHNrwN8TjqtIP7Rc+MYPx3aKZDK+aR5rHNK9iZe6St8QAj54yWtZv9rLLYjR+r ZdvsaVM+ojZuU6jD51MzcMsXws9sc8WHRlslFe13qOBl+IMQfyGyl5h3ElLMezt3 dbGkc/MW8l8bvF0aa0caWan2EHdz6POejZ70JAJIOztCCK/97ovGKsWhgVs1u0Tz CfQ0SX6RP1GNe5ty/SB3RHT5NMVmYPBFZZs5M6PmpvXXCYK1DcedvEmlLuXiYk2f Ws6te9NvavJswVVQbzl2a9LRLdViaWtII4y4sbpbN5G6lq8L4DH5pCu9QXW8Vk1a YHs6+lOflz873eycyHsmp8O576Pe/Iu9MqCfl6u7kzpzOsjgvv0=
=pUQQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On Tue, May 20, 2025 at 10:50:50AM -0400, Dan Purgert wrote:

[...]

I used /mnt/backup because I only wanted the partition mounted while the backup was running (it was one of several on that physical drive). The
backup script did the mount/rsync/unmount as part of the execution.
Really, the only point of this was a "well, I can't accidentally delete
it if it's not mounted" train of thought.

Aha. This looks a lot like my backup setup (I use /media/backup, though).
A user-sepecific backup dir (as DEs typically do) doesn't make much
sense here, because /etc (and several /home/) are backed up.

In my case the backup medium is LUKS encrypted, so the script first
calls "cryptsetup open", which asks me about the passphrase: this
does enough lockstep, IMO. Then fsck before mount, and after umount,
so I can be less anxious about file system corruption (it's an USB
stick, after all): as a bonus it shows me how much space is left.

Works like a charm.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaCyd3AAKCRAFyCz1etHa RttcAJ9vFZVoM/Y5v554WIZ3QxpnV9ed/ACeMLYz6+2P+MuaBl73BCgiQlkPA/Q=
=FVx1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 20, 2025 at 11:35:14AM -0400, Lee wrote:

On Tue, May 20, 2025 at 10:08 AM tomas wrote:

On Tue, May 20, 2025 at 09:45:11AM -0400, Lee wrote:

On Tue, May 20, 2025 at 9:33 AM wrote:

[...]

What do you do if you get two USBs containing file systems with
the same UUID?

Is that possible? I suppose it is.. so I'd go looking for how to
change the UUID for one of the usb drives.

If you copy a whole file system (e.g. with dd), the UUID will
travel with it. It's just data, after all. Sometimes you want it,
sometimes not.

If I'm copying from one usb to another it seems like I really would
not want the same UUID on both usb sticks.
And it sounds like it would be fairly easy to fix the duplicate UUID problem..

Yes, but copy programs (be it dd or cp or whatever you use) just
see a "stream of bytes" and try, as hard as they can, to copy it
faithfully.

Of course, if you *make* a second file system and copy the content,
the UUID will be most probably different (you can set it, for ext*
file systems with tune2fs).

Sometimes you *want* the same UUID. Imagine an application which
starts automatically when it "sees" a medium with a given UUID
inserted (I once made such a thing for a customer: an udev rule
kicked off a backup when the right USB disk was inserted into
a headless box). If you make a backup medium for the case your
primary breaks, you *want* the same UUID.

If you then modify one file system's content, you'll get two
file systems with the same UUID and... with different data =:-o

The horrors :)

Remember: the second "U" in "UUID" is a lie ;-)

uhmm... to remember something one first has to know/learn it.
I'm asking all these ignorant questions because I'm not there yet.

It wasn't meant personally, I'd be very sorry if I came across like
that.

I just wanted to counter the all too uncritical perception that
UUIDs Are Good. They are useful, but to make use of them one should
know their properties :-)

Cheers
--
tomás

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaCykKwAKCRAFyCz1etHa Rge7AJ0cYbaeIRr70TFtOfKwr+okzS00MgCfc/8fY1pxJ0QyF32lLgur8ObWWp4=
=Dktx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)