Introduction

The scene depicts Sisyphus, condemned by the gods to eternally push a boulder uphill, only to see it roll back before the top. Copying and pasting directories/folders is one of the most common - and most dangerous - practices when we handle important data.

It "works" most of the time, but fails exactly when it matters to fail visibly.

Copy and paste does not answer fundamental questions:

  • What changed?
  • What was overwritten?
  • What was left behind?
  • Can I prove two directories are equal?
  • What failed silently?

In the absence of these answers, we create an illusion of safety.

This article starts from a simple premise: filesystem is state, not just a set of files. And it shows why an approach based on explicit diff, auditing, and conscious synchronization solves problems that the operating system - and most tools - ignore.

The real problem: divergent states

Consider two directories:

  • A: work environment
  • B: backup, NAS, server, or staging environment

They are not just "folders". They represent distinct states in time.

Between A and B there are accumulated differences:

  • files created
  • files modified
  • files removed
  • read failures
  • different permissions

Copy and paste tries to replace one state with another without understanding these differences.

It is a blind operation.

Engineering requires the opposite:

understand the diff before applying any change.

Filesystem is not just file

In real environments, filesystem is never homogeneous.

There are:

  • sockets (ex: mysql.sock)
  • files accessible only as root
  • broken symlinks
  • Docker volumes mounted inside directories
  • files that disappear during the scan
  • inconsistent permissions
  • names valid in one filesystem and invalid in another

Naive scripts assume everything is a regular file. They break.

Robust tools do something different:

  • identify the entity type
  • classify the risk
  • decide what to ignore
  • log what cannot be processed

Before copying anything, you need to understand the terrain.

Explicit diff as the central concept

The right approach starts with a simple principle:

Never synchronize without knowing exactly what will change.

Instead of "copy everything", a conscious approach separates the problem into explicit categories:

  • missing directories
  • new files
  • modified files
  • extra files in the destination

Each category represents a different type of decision.

This turns a destructive operation - overwriting data - into an auditable process, where:

  • nothing happens by accident
  • nothing is silent
  • everything can be explained later

Diff stops being a technical detail and becomes the central object of decision.

Where most tools fail

Many tools even implement synchronization, but:

  • mix diff with execution
  • do not distinguish error from absence
  • hide permission failures
  • normalize names silently
  • treat dry-run as "almost execution"

This creates a false sense of control.

In practice, the user does not know:

  • what was actually copied
  • what was ignored
  • what failed
  • whether the final state is trustworthy

A conscious approach: fsync-conscious

It was from this set of problems that fsync-conscious emerged.

Not as an attempt to replace established tools, but as an explicit materialization of this mental model.

The tool starts from clear decisions:

  • diff explicitly always comes before sync
  • filesystem is treated as mutable state
  • failures are classified, not hidden
  • dry-run executes all logic, without side effects
  • hash is optional, not a dogma
  • nothing is renamed or "fixed" automatically

Instead of asking "did it copy or not?", the tool answers:

what changed, why it changed, and what could not be processed.

The project:

Hash is not a guarantee, it is a privilege

There is a common fetish in engineering:

"Without hash, it is not safe."

In practice, this ignores the real world.

Comparing files by hash requires:

  • full read permission
  • file stability during reading
  • relevant computational cost
  • more failure points

That is why a conscious tool:

  • uses mtime as default
  • allows hash as a strong mode (--hash)
  • tolerates read failures
  • logs unreadable files
  • continues operating

This behavior enables pragmatic engineering aligned with professional backup tools.

Conclusion

Copy and paste solves an action. Conscious synchronization solves a process.

When data matters:

  • visibility wins over convenience
  • explicit control wins over blind automatism
  • auditing wins over implicit trust

Thinking about filesystem as state changes everything:

  • it changes how you copy
  • it changes how you validate
  • it changes how you trust

Tools like fsync-conscious do not exist to "make life easier", but to make behavior explicit.

And, in engineering, that is what separates chance from responsibility.