FileSetTime() erronously rounds UP on non NTFS partition

[pseakins]

If executed on a FAT drive the following script will fail (reports incorrect timestamp). It works correctly on an NTFS drive. XP-Pro-SP2

#include <File.au3>
$TempFile = _TempFile(@ScriptDir, 'tst', '.txt', 5)
$handle = FileOpen($TempFile, 1)
If $handle = -1 Then
  MsgBox("", "", 'Unable to open temporary file "' & $TempFile & '".')
  Exit
EndIf
FileWrite($handle, "test")
FileClose($handle)
$timeset = '20071219184516'
FileSetTime($TempFile, $timeset, 0)
$timeget = FileGetTime($TempFile, 0, 1)
FileDelete($TempFile)
If $timeget <> $timeset Then
  MsgBox("", "", 'File timestamp is WRONG' & @CRLF & _
  'It should be ' & $timeset & @CRLF & _
  'instead, it is ' & $timeget)
Else
  MsgBox("", "", 'Timestamp is CORRECT')
EndIf

[anonymous]

Without testing or anything, this sounds to me like you've run into the 2 second timestamp resolution time on FAT partitions. On FAT, timestamps are only accurate to within 2 seconds. This is a limitation of the filesystem. If that's what's going on here, then it's not a bug.

[Valik]

Oops, I wasn't logged in. The last comment was from me.

[jpm]

(In [2762]) Public:
Fixed #19: FileSetTime() erronously rounds UP on non NTFS partition.

[Phil Seakins <pseakins@…>]

Valik. This is a bug. I would suggest you test it. I am well aware of the two second granularity of FAT partitions. What this bug is doing is adding two seconds to the specified time. If you set it to 19:14:16 it actually gets set to 19:14:18. As a workaround I have had to write special code to decrement the timestamp by TWO seconds before calling FileSetTime. Eg, to set it to 19:14:16 I need to specify 19:14:14. Using Borland's "Touch.exe" on the same filesystem yields correct results. AutoIt's FileSetTime() per the example, gives the wrong result. To save typing in a long explanation in the initial report I created and tested the working example.

I get so mad when people don't take my reports seriously.

[Valik]

In case you didn't pay attention, JP fixed the issue, or so the commit message says. There was no need to re-open the ticket just to rant at me when somebody else already addressed the problem. I'm re-closing this.

[Phil Seakins <pseakins@…>]

I'm sorry, I don't understand. What do you mean it was fixed? Jpm changed the assignment to fixed, but I don't see any indication of how it was fixed. Has the fix been applied to a new release? It doesn't say so in any of the comments assigned to this report?

[Valik]

Replying to jpm:

(In [2762]) Public:
Fixed #19: FileSetTime() erronously rounds UP on non NTFS partition.

^{That message. And STOP re-opening this. It's FIXED. I don't know what else you are expecting. AutoIt is closed source, it's not like you're going to see a patch attached. We aren't going to do a spot release for some insignificant bug like this. So other than the above message (Which in my opinion is pretty clear since it says it was fixed), how do you expect us to convey to you that the issue is fixed?}

This works just like the bug reports forum, people. You report a bug. We fix it, mark it as fixed (and set the milestone to the version it will appear in). But at any rate, once something is marked as fixed wait for the next release. Seriously, don't re-open tickets about a bug until you've actually tested that the bug is not fixed. It's extremely rude and obnoxious to continually re-open a ticket the developers have closed, whether you agree or understand or not. This will be the second time I've closed the ticket which is the third time after the automatic closing from JP's fix commit.

[Phil Seakins <pseakins@…>]

I am sorry. I thought that the ticket had been dismissed and marked as "fixed" due to a misunderstanding about timestamp granularity. I see now that if that were the case it would have been flagged as "rejected" or "wontfix". I understand now that it has actually been fixed which is great, I couldn't ask for anything more.

(I'm wondering why I am not getting CC'd on changes to this ticket. Also, when I view "My Tickets" I get zero results but that feature may only be available to administrators).