Modify

Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#19 closed Bug (Fixed)

FileSetTime() erronously rounds UP on non NTFS partition

Reported by: pseakins Owned by: Jpm
Milestone: 3.2.11.0 Component: AutoIt
Version: 3.2.10.0 Severity:
Keywords: XP Pro Sp2 Cc: pseakins@…

Description

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

Attachments (0)

Change History (11)

comment:1 Changed 17 years ago by Jpm

  • Owner set to Jpm
  • Status changed from new to assigned

comment:2 Changed 17 years ago by Jpm

  • Keywords XP Pro Sp2 added; FileSetTime removed

comment:3 Changed 17 years ago by 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.

comment:4 Changed 17 years ago by Valik

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

comment:5 follow-up: Changed 17 years ago by jpm

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:6 Changed 17 years ago by Jon

  • Milestone set to 3.2.11.0

comment:7 Changed 17 years ago by Phil Seakins <pseakins@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:8 Changed 17 years ago by Valik

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:9 Changed 17 years ago by Phil Seakins <pseakins@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

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?

comment:10 in reply to: ↑ 5 Changed 17 years ago by Valik

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:11 Changed 17 years ago by 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).

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jpm.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.