Opened 15 years ago
Closed 15 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 Valik)
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)
comment:1 follow-up: ↓ 2 Changed 15 years ago by Jpm
- Resolution set to Works For Me
- Status changed from new to closed
comment:2 in reply to: ↑ 1 Changed 15 years ago by anonymous
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 Changed 15 years ago by Valik
- Description modified (diff)
comment:4 Changed 15 years ago by Valik
- Resolution Works For Me deleted
- Status changed from closed to 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()
comment:5 Changed 15 years ago by Jpm
I can reconfirm that's working under Vista/SP1 !!!
comment:6 follow-up: ↓ 7 Changed 15 years ago by Jpm
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 in reply to: ↑ 6 Changed 15 years ago by Jos
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 Changed 15 years ago by Jpm
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 Changed 15 years ago by Valik
- Milestone set to 3.3.1.2
- Resolution set to Fixed
- Status changed from reopened to 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.
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.
That's working fine under my Vista/SP1 system