Tags: stephenh/mirror
Tags
Bump grpc dependencies to resolve iisues with mac/centos. (#68) Admittedly I didn't do much digging but with a simple MacOS Big Sur / Centos environment, grpc ran into issues with netty... IllegalArgumentException: decode only works with an entire header block! which can be found here: https://netty.io/4.1/xref/io/netty/handler/codec/http2/HpackDecoder.html#456. Bumping grpc to latest resolves it. Co-authored-by: Ian V Koeppe <[email protected]>
Added functionality to be able to define the log file name, and the l… …og file path. Errors will be thrown if the directory does not exist, is not writable, or is not a logical directory. (#66) Co-authored-by: Barry Chapman <[email protected]>
Better handling of directory mod times. Mirror is fundamentally based on mod times, i.e. latest mod time wins. This works great for files, but directories are a bit different, because any new/changed file in a directory, updates the directory's own mod time to an OS-generated value. In general we don't want to bother with keeping these in-sync across local/remote, so now we explicitly ignore this case. Deletions also don't work well with mod times, b/c a deletion doesn't really have a time in the file system anymore; previously we added the old mod time + 1 second immediately when the delete happened, but this could result in an ignored write, hwen our "now + 1 second" hueristic was artificially ahead of an actual now + < 1 second write on the just-deleted file. We still need to fudge with mod times on "deleted then restored via mv" files, to ensure their still-in-the-past-b/c-it-was-restored mod time "wins" over the deletion mark, so we recognize when that is happening and bump the restored file's mod time ahead by 1 second.
Better handling of directory mod times. Mirror is fundamentally based on mod times, i.e. latest mod time wins. This works great for files, but directories are a bit different, because any new/changed file in a directory, updates the directory's own mod time to an OS-generated value. In general we don't want to bother with keeping these in-sync across local/remote, so now we explicitly ignore this case. Deletions also don't work well with mod times, b/c a deletion doesn't really have a time in the file system anymore; previously we added the old mod time + 1 second immediately when the delete happened, but this could result in an ignored write, hwen our "now + 1 second" hueristic was artificially ahead of an actual now + < 1 second write on the just-deleted file. We still need to fudge with mod times on "deleted then restored via mv" files, to ensure their still-in-the-past-b/c-it-was-restored mod time "wins" over the deletion mark, so we recognize when that is happening and bump the restored file's mod time ahead by 1 second.
PreviousNext