Support for hard links

[bkeadle]

I'd like to try again to make a case for adding an option for hard links.
Though previously requested implementing hard links for the file revisions
feature, I'd like to suggest that even as a sync option would be huge
advantage. Granted, the sync operation would have to exist on the same volume,
and a volume that supports hardl inks (NTFS, some NAS devices), but that's OK.

Initially, the scenario would be to duplicate a source directory to a target
destination with all hard links, then I could do a sync from a second source
to the target destination, and where files on the source are different than
the target, I would do a (real) file copy. This would allow me to create a
daily backup of a source directory to a target directory, and in effect de-
dupe each daily backup to be only changed files, yet appear as a full.

For example, I have an 30 GB email volume with over 2 million files. Only a
fraction of those files are changed on a daily basis. So on day 1, I would
create a first full backup from EMAIL volume to EMAIL-BACKUP\YYYY-MM-01 (disk
usage = 30GB) My sync job after that would look like:

- Hard link sync from EMAIL-BACKUP\YYYY-MM-01 to EMAIL-BACKUP\YYYY-MM-02
- Sync from EMAIL to EMAIL-BACKUP\YYYY-MM-02

and so on...

- hard link sync from EMAIL-BACKUP\YYYY-MM-02 to EMAIL-BACKUP\YYYY-MM-03
- sync from EMAIL to EMAIL-BACKUP\YYYY-MM-03

The result will be a daily full backup folder, but unique files only taking up
disk space once. So instead of each dated folder consuming 30 GB of raw disk,
each subsequent dated folder would only consume the space of files that have
changed since the previous day - perhaps a few 100 MB.

I envision something like a "use hard links" in the Mirror sync option.



a sync between a source and a destination.

[dmangum250]

I second the motion! Such linking might be considered the poor man's de-
duplication and would provide much of the benefits.

[Zenju]

FreeFileSync is generally a mainstream tool; hard-links are too low-level a
concept to be useful for most users. Sure it solves the full backup scenario
quite well (not perfect though: nothing prevents the user from modifying the
backup drive and unconsciously corrupting shared old versions of a file as
well! A ref-count > 1 is not visualized by any standard Windows tool!) but I
don't see them solve another relevant scenario. Their usefulness is further
reduced by their implementation constraints: On Windows: require NTFS, can
only reference files on the same volume.

[bkeadle]

True - the (significant) advantages of hard links has it's conditions. I
should add though, on Windows, it's limited to NTFS for local volumes, but
many NAS file systems (to which I would think is another major target for
keeping backups) also support hard links. It's certainly not a one size-fits-
all ... that's why it would be an "option"! :-) When setting up a sync pair, a
quick test against the destination as to whether a hard can be created (create
a dummy file, then create a hard link to the dummy file) would allow
for/enable hard link option. "Hard link" wouldn't need to be understood by the
novice user, you simply offer "space saving technology" or "de-duplicate data"
for the revision feature.

I stumbled across
LuckyBackup, a different
utility that offers "snapshots", which I wonder isn't using hard links.
Another attractive feature of LuckyBackup (LB) is it's use of rsync, thus able
to make block-level copies instead of full copies of changed files, thus great
reducing the sync time for large backup/syncs. Perhaps there might be some
feature ideas for FFS future development?! The Windows port of LB is a bit
lacking, so it wouldn't be a replacement of FFS, though as a backup/sync tool
for local drives, it's use of rsync and "snapshots" is likely a better
solution if speed and "space saving" is important. FFS's implementation of
hard links would mitigate the space saving advantage.

Point taken about how if a user modifies a backup file that he ends up
changing all hard-linked references to that file, but that seems to be an
unusual scenario to be manually editing revisioned files. I would think
revisioned files within a backup set is to be *restored*, not modified in
place.

[biep]

This would provide what Hermann Schinagl calls DeLorean copies, right? That would be a wonderful thing!

P.S.: It would be nice if the documentation explained what happens with existing hard links on one side - will corresponding hard links be made on the other side?
E.g.:
> source\A.txt == source\B.txt (two hard links to one file)
> Sync source => dest
> Will this lead to dest\A.txt == dest\B.txt ?