Re: [tcljava-dev] Jacl and file mtime

[Mo D. <md...@cy...>]

On Mon, 8 Jan 2001, Christian Krone wrote:

> Hello,
> 
> Christian Sorensen wrote:
> 
> > I am using the Java implementation of Tcl, called Jacl, version 1.2.6.
> 
> > I just tried to use the "file mtime <filename>" command and found out that
> > it does not work properly (on Windows 95/NT, that is). The reason seems to
> > be that the Tcl concept of integers is 32-bit and that the Java
> > File.getModified() method returns a long too long to be stored in an int.
> > By experimenting with  File.getModified() in pure Java (on Windows 95) I
> > found out that the three rigtmost digits of this huge number always were
> > "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> > time / 1000, "file mtime" became acceptable for an int - and it became
> > useful, e.g. for "make" like utilities.
> 
> The JavaDoc of File.lastModified() explicitely mentions, that the return value
> should be interpreted in milliseconds. So I think that the implementation
> of FileCmd.getMtime() is just wrong. It should devide the long value by 1000
> any way to receive a valid date in seconds.
> 
> > What happens on non-Windows platforms I don't know.
> 
> I wonder why the comment in FileCmd.java above the definition of getMtime()
> states that the return value of File.lastModified() is platform dependent.
> This is not mentioned by the docs and at least on Linux and Windows the
> return value is actually the same: the amount of millis since the Epoch.
> 
> I think the patch should devide by 1000 and should remove the comment also...
> So it would read like the following:
> 
> ---- FileCmd.java~       Wed Aug 16 06:45:36 2000
> +++ FileCmd.java        Mon Jan  8 09:09:05 2001
> @@ -462,9 +462,6 @@
>   * getMtime --
>   *
>   *     Finds the last modification of file in fileObj.
> - *     WARNING:   The return value of lastModified() is system dependent and
> - *     should only be used to compare with other values returned by last
> - *     modified. It should not be interpreted as an absolute time.
>   *
>   * Results:
>   *     Returns an int representation of modification time.
> @@ -488,7 +485,7 @@
>         throw new TclPosixException(interp, TclPosixException.ENOENT, true,
>                 "could not read \"" + fileName + "\"");
>      }
> -    return (int) fileObj.lastModified();
> +    return (int) (fileObj.lastModified() / 1000);
>  }

I would have no problem with this patch as long
as there is a test case that shows the bug
before the patch and no bug after the patch.
The tests are a bit of a mess right now, so
I think the most safe bet would be to put
the test in tcljava/tests/jacl/FileCmd.test.

Mo DeJong
Red Hat Inc