Opened 16 years ago
Closed 16 years ago
#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 , 16 years ago
| Resolution: | → Works For Me |
|---|---|
| Status: | new → closed |
comment:2 by , 16 years ago
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 , 16 years ago
| Description: | modified (diff) |
|---|
comment:4 by , 16 years ago
| 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 , 16 years ago
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 , 16 years ago
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 , 16 years ago
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 , 16 years ago
| 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