Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267571 > unrolled thread

Hard links - How do they work

Back to article view | Back to linux.debian.user

Contents

  Hard links - How do they work Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 01:00 +0100
    Timeshift / Back In Time - How do they work Andy Smith <andy@strugglers.net> - 2024-02-19 01:10 +0100
    Re: Hard links - How do they work Kushal Kumaran <kushal@locationd.net> - 2024-02-19 01:20 +0100
      Re: Hard links - How do they work: TANSTAAFL Charles Curley <charlescurley@charlescurley.com> - 2024-02-19 03:00 +0100
      Re: Hard links - How do they work Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 03:40 +0100
    Re: Hard links - How do they work Dan Ritter <dsr@randomstring.org> - 2024-02-19 13:20 +0100

#267571 — Hard links - How do they work

As promised:
I said sometime in this thread that timeshift (and Back in Time) use 
hard links to create progressive copies of the system. The more I think 
about how hard links reportedly work, I reckon it can't be simply hard 
links.

So I'm starting a new thread on that topic.

My understanding is that a hard link (ln with no option) will list the 
file in another directory, but the file remains the same no matter where 
I may edit it.    I use cp -lru as a quick and dirty way to protect me 
against accident deleting a file. (Sym-link doesn't give that 
protection, but does allow me to keep my home on a separate partition so 
that a fresh install is a LOT easier; but that is another topic)

Snapshots reportedly hard link the directory/ies (generally means /  but 
not limited ). a new snapshot copies the latest set and then updates any 
new files in the base.    The more I try to visualise that process the 
more I reckon there must be more to it

Anybody care to fill me in please?

I am mindful that it is late Sunday night for many of you


-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [next] | [standalone]

#267572 — Timeshift / Back In Time - How do they work

Hi,

On Mon, Feb 19, 2024 at 10:52:16AM +1100, Keith Bainbridge wrote:
> I said sometime in this thread that timeshift (and Back in Time) use hard
> links to create progressive copies of the system. The more I think about how
> hard links reportedly work, I reckon it can't be simply hard links.

I can tell you how hardlinks work but I can't tell you how
Timeshift or Back In Time work as I have never used them. So you
might want to alter your subject line, because your email goes on
only to ask how these solutions work

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#267573

On Mon, Feb 19 2024 at 10:52:16 AM, Keith Bainbridge <keithrbau@gmail.com> wrote:
> As promised:
> I said sometime in this thread that timeshift (and Back in Time) use
> hard links to create progressive copies of the system. The more I
> think about how hard links reportedly work, I reckon it can't be
> simply hard links.
>
> So I'm starting a new thread on that topic.
>
> My understanding is that a hard link (ln with no option) will list the
> file in another directory, but the file remains the same no matter
> where I may edit it.    I use cp -lru as a quick and dirty way to
> protect me against accident deleting a file. (Sym-link doesn't give
> that protection, but does allow me to keep my home on a separate
> partition so that a fresh install is a LOT easier; but that is another
> topic)
>
> Snapshots reportedly hard link the directory/ies (generally means /
> but not limited ). a new snapshot copies the latest set and then
> updates any new files in the base.    The more I try to visualise that
> process the more I reckon there must be more to it
>
> Anybody care to fill me in please?
>

Have you read their FAQ page about hard links?
https://github.com/bit-team/backintime/blob/dev/FAQ.md#how-do-snapshots-with-hard-links-work

> I am mindful that it is late Sunday night for many of you

[toc] | [prev] | [next] | [standalone]

#267574 — Re: Hard links - How do they work: TANSTAAFL

On Sun, 18 Feb 2024 16:15:01 -0800
Kushal Kumaran <kushal@locationd.net> wrote:

> Have you read their FAQ page about hard links?
> https://github.com/bit-team/backintime/blob/dev/FAQ.md#how-do-snapshots-with-hard-links-work

An excellent writeup. The only thing I would add is that creating a
hard link does require an entry in a directory somewhere. If that
requires adding a block to the directory entry, that will happen. So
hard links are not entirely free. TANSTAAFL: There Ain't No Such Thing
As A Free Link.

But I doubt that this explains all of Keith Bainbridge
<keithrbau@gmail.com>'s problem.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#267576

On 19/2/24 11:15, Kushal Kumaran wrote:
> Have you read their FAQ page about hard links?
> https://github.com/bit-team/backintime/blob/dev/FAQ.md#how-do-snapshots- 
> with-hard-links-work


Very interesting.  Thank you


I have totally missed the concept of copying all files as a starting point.

I was dismayed to read that a file that was deleted disappears from the 
back up as well.  UMMM I didn't know I had deleted that file. A 
month/year later I NEED it quickly. What to do?

I went back to timeshift and looking again, this concept of copying all 
files seems to be used here as well. The author does say that the app 
uses btrfs inbuilt snapshot process when available.

I have to look harder when I browse over something.   Is it looking 
obvious that I never really learnt how to read, 70 years ago in primary 
school.


-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267587

Keith Bainbridge wrote: 
> As promised:
> I said sometime in this thread that timeshift (and Back in Time) use hard
> links to create progressive copies of the system. The more I think about how
> hard links reportedly work, I reckon it can't be simply hard links.
> 
> So I'm starting a new thread on that topic.
> 
> My understanding is that a hard link (ln with no option) will list the file
> in another directory, but the file remains the same no matter where I may
> edit it.    I use cp -lru as a quick and dirty way to protect me against
> accident deleting a file. (Sym-link doesn't give that protection, but does
> allow me to keep my home on a separate partition so that a fresh install is
> a LOT easier; but that is another topic)

A hard link is a name for a file -- it points to the first inode. Most
files only have one name, but they can have many. Hard links can be in
many directories, but must stay on the same filesystem. If you
mv the file by any of its links on the same filesystem, all the
links remain valid. When the last name for a file is deleted,
the file is deleted. Now you know why deleting a file is
sometimes called "unlinking".

A symbolic link is a tiny file that contains a path to a file.
The kernel reads the path, then looks for the substitute file.
This can fail. But -- it can cross filesystems, even filesystems
of completely different types. If you move the symbolic link, it
continues to point to the same path. If you move the referenced
file, the symbolic links are no longer valid.


> Snapshots reportedly hard link the directory/ies (generally means /  but not
> limited ). a new snapshot copies the latest set and then updates any new
> files in the base.    The more I try to visualise that process the more I
> reckon there must be more to it

"snapshot" is not a single definition; the software you are using
produces different results.

rsnapshot/rsync, lvm, btrfs and zfs, for example, each use completely
different mechanisms with different semantics.

It looks like timeshift uses either rsync or btrfs snapshots,
and backintime uses rsync, so first you would need to define which of those you are using
and in what mode.

-dsr-

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web