#1183 closed Bug (Fixed)
FileSetTime can't set filetime
| Reported by: | anonymous | Owned by: | |
|---|---|---|---|
| Milestone: | 3.3.1.2 | Component: | AutoIt |
| Version: | 3.3.1.1 | Severity: | None |
| Keywords: | Cc: |
Description (last modified by )
FileSetTime can't set filetime of a file. It seems that AutoIt can't find the file when located in a subdirectory.
It is an issue of the beta version. In AutoIt v3.3.0.0 everything
works fine.
Script used for testing:
$sFilename="C:\Test\file.zip" If FileExists($sFilename) Then MsgBox(4096, "Test", FileGetTime($sFilename, 1, 1)) MsgBox(4096, "Test", FileSetTime($sFilename, "20031101", 0, 0)) endif $sFilename="C:\Test\NextLevel\file.zip" If FileExists($sFilename) Then MsgBox(4096, "Test", FileGetTime($sFilename, 1, 1)) MsgBox(4096, "Test", FileSetTime($sFilename, "20031101", 0, 0)) endif
Results: correct Timestamp, 1, correct Timestamp, 0
Comment: same file, same attributes
See similar forumpost:
http://www.autoitscript.com/forum/index.php?showtopic=101917&st=0&p=724083&hl=FileSetTime&fromsearch=1&#entry724083
Attachments (0)
Change History (9)
follow-up: 2 comment:1 by , on Sep 17, 2009 at 6:10:43 PM
| Resolution: | → Works For Me |
|---|---|
| Status: | new → closed |
comment:2 by , on Sep 18, 2009 at 11:52:45 AM
Replying to Jpm:
That's working fine under my Vista/SP1 system
I'm working on XP/SP3. Times of File "C:\Test\NextLevel\file.zip" ist not changed and FileSetTime returns "0".
comment:3 by , on Sep 18, 2009 at 4:48:40 PM
| Description: | modified (diff) |
|---|
comment:4 by , on Sep 18, 2009 at 5:01:53 PM
| Resolution: | Works For Me |
|---|---|
| Status: | closed → reopened |
I can confirm the behavior on Windows XP SP3 with the following script:
Local Const $sRootDir = "C:\Test"
Local Const $sFile1 = $sRootDir & "\file.zip"
Local Const $sFile2 = $sRootDir & "\NextLevel\file.zip"
Local Const $sTime = "200311010000"
If Not TouchFile($sFile1) Then Exit -1
If Not TouchFile($sFile2) Then Exit -2
SetTime($sFile1, $sTime)
SetTime($sFile2, $sTime)
DirRemove($sRootDir, True)
Func TouchFile($sFile)
Local $hFile = FileOpen($sFile, 10)
If $hFile = -1 Then
ConsoleWrite("Unable to open file: " & $sFile)
Return False
EndIf
FileWrite($hFile, "Delete this file if present.")
FileClose($hFile)
Return True
EndFunc ; TouchFile()
Func SetTime($sFile, $sTime)
ConsoleWrite("Time for: " & $sFile & @CRLF)
Local $sResult = FileGetTime($sFile, 0, 1)
ConsoleWrite(@TAB & "Before: " & $sResult & " (" & @error & ")" & @CRLF)
ConsoleWrite(@TAB & " Result: " & FileSetTime($sFile, $sTime, 0, 0) & @CRLF)
$sResult = FileGetTime($sFile, 0, 1)
ConsoleWrite(@TAB & "After: " & $sResult & " (" & @error & ")" & @CRLF)
EndFunc ; SetTime()
follow-up: 7 comment:6 by , on Sep 20, 2009 at 10:01:14 AM
running under XP/SP2 under vmware is OK too
>Running:(3.3.0.0):C:\Program Files\AutoIt3\autoit3.exe "C:\Users\Jpm\Desktop\#1183 FilesetTime subdir.au3" Time for: C:\Test\file.zip Before: 20090920105937 (0) Result: 1 After: 20031101000037 (0) Time for: C:\Test\NextLevel\file.zip Before: 20090920105937 (0) Result: 1 After: 20031101000037 (0) +>10:59:38 AutoIT3.exe ended.rc:0
comment:7 by , on Sep 20, 2009 at 11:25:45 AM
Replying to Jpm:
>Running:(3.3.0.0):C:\Program Files\AutoIt3\autoit3.exe "C:\Users\Jpm\Desktop\#1183 FilesetTime subdir.au3"
JP, Have you also tried with the Latest Beta because the OP stated that 3.3.0.0 was not showing the issue?
For me it works fine with 3.3.0.0 and fails with 3.3.1.1 on the second datechange.
Jos
comment:8 by , on Sep 20, 2009 at 6:01:43 PM
Jos,
True I was checking only under 3.3.0.0.
But for what I don't understand the tentative 3.3.1.2 is working OK.
comment:9 by , on Sep 20, 2009 at 6:37:24 PM
| Milestone: | → 3.3.1.2 |
|---|---|
| Resolution: | → Fixed |
| Status: | reopened → closed |
Revision [4778] probably fixed it. Just a guess, though. However, the function is still broken and I think the design is not very good. If there is a problem when recursively setting the time for a directory, there are two ways it can fail that do not restore the original working directory. I saw this looking at the code to see if this problem was fixed. To this end I've created #1187.
I'm closing this ticket since it is fixed.

That's working fine under my Vista/SP1 system