Bug 12915 - --modify-window should default to 1 for fat filesystems
--modify-window should default to 1 for fat filesystems
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.3
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-18 22:19 UTC by Ian Kelling
Modified: 2017-07-19 18:30 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Kelling 2017-07-18 22:19:28 UTC
The manual on --modify-window says "Specifying 1 is useful for copies
to/from MS Windows FAT filesystems, because FAT represents times with a
2-second resolution (allowing times to differ from the original by up to
1 second)."

So make 1 the default if we can detect that it's a FAT filesystem.
Comment 1 Kevin Korb 2017-07-19 00:28:55 UTC
This would not actually be very helpful.  Going between a *nix style timestamp and a FAT one has other issues.  Especially if your TZ changes or you are in a TZ where the clock changes twice per year.  Your modify windows will need to be 2 + (number of hours difference * 3600) which is kind of an unsafe thing to do.  FAT just isn't capable of keeping proper timestamps.
Comment 2 Ian Kelling 2017-07-19 02:07:13 UTC
> This would not actually be very helpful.

Why? You haven't said. The manual says it's helpful
and it's helpful for me.
Comment 3 Brian K. White 2017-07-19 02:38:46 UTC
(In reply to Ian Kelling from comment #2)

The manuals says useful not helpful. The manual does not say it's good or bad or recommended or any other value judgement. It only describes it's function and the reason for it's existence. It does not say you automatically always want it, even in that special case it was created for.

I'm not sure why it would automatically be a bad default either, just pointing out that the manual makes no such claim that it is a good default.
Comment 4 Kevin Korb 2017-07-19 06:49:22 UTC
The manual says that with FAT you need --modify-window=2 not 1.  But here in the US for half of the year you need --modify-window=3602 instead.  The same goes for many other locations.  The simple fact of the matter is that FAT is an obsolete filesystem designed for 5.25 inch floppy disks that is not in any way compatible to doing 1990's vintage things.  I know there are devices out there that are stuck with FAT but it is the user's job to adapt to their incapabilities not rsync's.

Years ago, when I still had a Win98 computer to backup I suggested that rsync should have a --fat option.  The --fat option would would have omitted --owner, --group, --permissions from --archive and would have ignored an exactly 1 hour difference in time stamp (back then rsync only supported whole second time stamps anyway).  I was told no.  It isn't rsync's job to work around garbage filesystems that have been obsolete for decades.

Rsync should not be responsible for detecting what a filesystem can handle.  Many things can obscure those facts from rsync on a per-directory basis  (or even a per-file basis).  Rsync should do what it is told to do or it should report failure.  That is what it is doing.
Comment 5 Kevin Korb 2017-07-19 06:54:53 UTC
Actually, I looked it up.  It wasn't actually my request I had already dealt with the problem.

This is the ticket from the person I was helping: 
https://bugzilla.samba.org/show_bug.cgi?id=6927
Comment 6 Ben RUBSON 2017-07-19 06:58:41 UTC
Just to clarify, is FAT32 also impacted and requires --modify-window option, or only the old one FAT is ? Thx !
Comment 7 Ian Kelling 2017-07-19 14:18:45 UTC
> But here in the US for half of the year you need --modify-window=3602 instead.

I think people use vfat because there are a lot of devices out there
like android which require it, and they only care about timestamps in so
much as they can tell rsync which files need to be copied.  We are in
daylight savings right now, and syncing to filesystem made with
mkfs.vfat seems to work fine with less than 3602 modify window.

> Rsync should not be responsible for detecting what a filesystem can handle.  Many things can obscure those facts from rsync on a per-directory basis  (or even a per-file basis).

That's the only good argument I see. The bug asks if we can
detect it. If it's not feasable in normal efficient operation,
case closed.
Comment 8 Kevin Korb 2017-07-19 18:30:51 UTC
The 3602 problem happens when the clocks change not the entire time the clocks are different.  If you do a daily rsync then rsync will see 1 hour off timestamps the day after both clock changes.

Yes, this is all versions of FAT including FAT32.  Nobody really cares about FAT16 anymore.