On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote:
> Speaking for myself, I certainly have experienced issues with
> inaccurate timestamps on NFS for compute clusters where its use is
> very common. Not saying this as a supporter of NFS and the likes, just
> as evidence that it does
*** Pedro Lucas Porcellis [2022-02-01 11:00]:
>I think for most people out there, relying on mtime is just perfectly fine.
No. mtime depends on time and filesystem implementation specifics.
There are many systems where sysadmins like to do cron-ed ntpdate,
which leads to jumping clocks. There cou
On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote:
> On Tue 01 Feb 2022, NRK wrote:
> > On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> > > However, it was pointed out to me that relying on mtime can give
> > > wrong results, for example: (a) if the clock is set bac
On Tue 01 Feb 2022, NRK wrote:
> On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> > However, it was pointed out to me that relying on mtime can give wrong
> > results,
> > for example:
> > (a) if the clock is set backwards or in case of insufficient granularity in
> > mtime
> > t
On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> However, it was pointed out to me that relying on mtime can give wrong
> results,
> for example:
> (a) if the clock is set backwards or in case of insufficient granularity in
> mtime
> then a file that gets modified might have the
On Mon, Jan 31, 2022 at 09:34:52AM -0500, LM wrote:
Dear Laura,
> This looks like a very interesting project. I've been looking for some
> alternatives to GNU make.
I hope you find something to fit your needs.
> I do use a few GNU make features that I'm not sure about porting to other
> alterna
