rsync - Jul 2017 - [Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915

            Bug ID: 12915
           Summary: --modify-window should default to 1 for fat
                    filesystems
           Product: rsync
           Version: 3.1.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: iank at fsf.org
        QA Contact: rsync-qa at samba.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #1 from Kevin Korb <rsync at sanitarium.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #2 from Ian Kelling <iank at fsf.org>
---
> This would not actually be very helpful.
Why? You haven't said. The manual says it's helpful
and it's helpful for me.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #3 from Brian K. White <brian at aljex.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #4 from Kevin Korb <rsync at sanitarium.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #5 from Kevin Korb <rsync at sanitarium.net> ---
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #6 from Ben RUBSON <ben.rubson at gmail.com> ---
Just to clarify, is FAT32 also impacted and requires --modify-window option, or
only the old one FAT is ? Thx !

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #7 from Ian Kelling <iank at fsf.org>
---
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=12915

--- Comment #8 from Kevin Korb <rsync at sanitarium.net> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

> Rsync should not be responsible for detecting what a filesystem can handle.
That makes the most sense to me. There are countless filesystems, each 
with their own quirks, and countless mkfs and mount options which just 
multiplies the possible fs behaviors even more. Best to provide controls 
and options for low level features and behaviors, and let the user or a 
front end orchestrate using them however appropriate.

This argument falls apart a little bit if rsync ever does any other 
special built-in support for any other filesystems like nfs or something.

-- 
bkw