Change file create and modified time not working
Moderators: fgagnon, nikos, Site Mods
Change file create and modified time not working
Using version 2.0.0.1 on Win7 Pro SP1 (on a 32-bit system and also on a 64-bit system).
Highlighted (selected) a file, SHIFT-F12 to bring up Change Attributes dialog, ticked the box by Modified on: and used the spinner arrow to bump the time up by 1 second. Clicked OK. Time remains unchanged. Issuing SHIFT-F12 again, shows the original time and the modified box is still ticked.
Same for Created on: time.
I can change the hours and minutes on each, and can change the seconds to some larger increment (though I did notice x2 does not give me exact increment -- for example, if I bump up the current seconds to three higher, x2 makes the time four seconds higher).
Trying various increments of seconds several times (7 or 8 various attempts?) eventually brings up the Windows dialog, "xplorer2 - explorer replacement has stopped working" "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Highlighted (selected) a file, SHIFT-F12 to bring up Change Attributes dialog, ticked the box by Modified on: and used the spinner arrow to bump the time up by 1 second. Clicked OK. Time remains unchanged. Issuing SHIFT-F12 again, shows the original time and the modified box is still ticked.
Same for Created on: time.
I can change the hours and minutes on each, and can change the seconds to some larger increment (though I did notice x2 does not give me exact increment -- for example, if I bump up the current seconds to three higher, x2 makes the time four seconds higher).
Trying various increments of seconds several times (7 or 8 various attempts?) eventually brings up the Windows dialog, "xplorer2 - explorer replacement has stopped working" "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Are these two computers of yours by any chance named Bête noire and Petit noire?
They do seem quarrelsome.
I did 25 consecutive modification-date increments of 1-4 seconds on a single file and each one was accurate without causing a single crash. As x2 is crashing for you, find the minidump file in your user Application Data\Temp folder and send it to Nikos, as that way at least he might find what is interfering with the action.
I think I know what you're referring to though - while the actual timestamp of the file is indeed accurately updated even by 1 second (check in the Properties), the subsequent date that x2 puts in the adjustable dialog (when you next hit Shift-F12) is itself slightly out of sync, it does not appear to reflect the updated timestamp from the disc. This would seem to be a bug of sorts - Refreshing doesn't especially help, nor does selecting an alternate file then returning to the first - though moving to an entirely separate folder and back again (not a subfolder) does seem to work. It does appear to be limited to an accuracy radius of 2-3 seconds either way.
Yup, walks like a bug and talks like a bug.
![Wink :wink:](./images/smilies/icon_wink.gif)
I did 25 consecutive modification-date increments of 1-4 seconds on a single file and each one was accurate without causing a single crash. As x2 is crashing for you, find the minidump file in your user Application Data\Temp folder and send it to Nikos, as that way at least he might find what is interfering with the action.
I think I know what you're referring to though - while the actual timestamp of the file is indeed accurately updated even by 1 second (check in the Properties), the subsequent date that x2 puts in the adjustable dialog (when you next hit Shift-F12) is itself slightly out of sync, it does not appear to reflect the updated timestamp from the disc. This would seem to be a bug of sorts - Refreshing doesn't especially help, nor does selecting an alternate file then returning to the first - though moving to an entirely separate folder and back again (not a subfolder) does seem to work. It does appear to be limited to an accuracy radius of 2-3 seconds either way.
Yup, walks like a bug and talks like a bug.
Sounds suspiciously like a significant bit (precision) issue.
Windows uses 24 (or more) fractional bits for timekeeping.
[Hours, minutes, seconds are fractions of a day]
If, for example, nikos now only looks at the first 15 fractional bits for adjusting time, that could explain it: (LSB would be approximately 2.64 seconds).
Windows uses 24 (or more) fractional bits for timekeeping.
[Hours, minutes, seconds are fractions of a day]
If, for example, nikos now only looks at the first 15 fractional bits for adjusting time, that could explain it: (LSB would be approximately 2.64 seconds).
Nicely computed! :D (For the less technical in the audience, LSB is Least Significant Bit.)fgagnon wrote:(LSB would be approximately 2.64 seconds)
Do keep in mind I launch x2 with /M /N /P which makes it work differently than the default. In general using these switches *improves* my x2 experience substantially (for me it makes x2 much more predictable), the downside being sometimes I see problems other don't experience.
Don't know if these switches play a role in this particular problem but I wanted to mention anyway, as not everyone reads (or remembers) this information from my other posts![Smile :-)](./images/smilies/icon_smile.gif)
Don't know if these switches play a role in this particular problem but I wanted to mention anyway, as not everyone reads (or remembers) this information from my other posts
![Smile :-)](./images/smilies/icon_smile.gif)
Tosh, funny Greek-man, I can do this with a script no bother - you tellin' me I have to rewrite your Shift-F12 Window in AutoIt just to get an accurate toy that writes and then immediately reads back a true updated modified timestamp?nikos wrote:for all intents and purposes you won't get better accuracy than 2 seconds for file times with xplorer2/windows.
Code: Select all
$Name = "C:\WhatAreYouSmoking.txt"
$oFile = FileOpen($Name, 2)
FileWriteLine($oFile, "YoDudeMyGrannysHerbalTea")
FileClose($oFile)
$fTime1 = Int(FileGetTime($Name, 0, 1))
FileSetTime($Name, "20100320121247")
$fTime2 = Int(FileGetTime($Name, 0, 1))
FileSetTime($Name, "20100320121248")
$fTime3 = Int(FileGetTime($Name, 0, 1))
FileSetTime($Name, "20100320121249")
$fTime4 = Int(FileGetTime($Name, 0, 1))
MsgBox(0, "", "Created at: " & $fTime1 & @LF & _
"Changed to: " & @TAB & $fTime2 & @LF & _
"+1 Second: " & @TAB & $fTime3 & @LF & _
"+1 Second: " & @TAB & $fTime4)
![Image](http://i1109.photobucket.com/albums/h440/Kilmatead/Times.png)
This is a known crash-bug in X², see this post from May. I remember it being a lot more common before the build Nikos mentioned in that post came out, but alas the crash still does still happen. (We never resolved it because for months I wasn't receiving notification emails from this forum and didn't know why - which I think I fixed a few weeks ago :/ )nikos wrote:...As for the crash if you can do it again reliably please use Help > Crash information menu command to send me the crash information file
Nikos, I should be able to get a crash dump for you when I'm on my home computer next. The crash is very predictable - it happens to me nearly everytime I change multiple attributes fast.
My workaround has been to change attributes 'slowly', i.e. make a change, let X² rest for a few seconds, then make another change. To add some context, I have to do this since X² won't let me set the Read-Only flag and the Last Modified Date field at the same time
![cry :cry:](./images/smilies/cry.gif)
Reproduction Steps:
- To minimize possible culprits... Open a fresh instance of X² with a single tab in a single pane. Create or goto a folder with only a single file in it. Remove all Columns from your view except the name column. Select this single file.
- Shift+F12 - check the 'Modified on:' field, and uncheck everything else.
- Click Ok. Wait 4 seconds.
- Shift+F12 - verify that only the 'Modified on:' field is checked. Change the 'day' to something different - remember what the value was and what it is being changed to.
- Click Ok, then quickly press Shift+F12. Notice that the day value has not updated. If it has, then try again - you weren't fast enough
- Change the day value to a 3rd value and click Ok.
- Observe X² crash - if it does not, retry steps 4-6 faster.
-Thracx
"Man wants to know, and when he ceases to do so, he is no longer a man."
-Fridtjof Nansen
"Man wants to know, and when he ceases to do so, he is no longer a man."
-Fridtjof Nansen
Even following your detailed instructions above, I am as unable to reproduce this now as I was back in May - I surmise something else is at play here - the minidump may be the only means of telling.Thracx wrote:This is a known crash-bug in X², see this post from May.
I managed somewhere around 40 consecutive modifications within about a minute before I lost count, each one with a new modification date setting, manually adjusted (as fast as possible). It simply would not crash.
Edit: I even repeated this on three different files of varying types and sizes on three different drives, none of which share the same RPM count, just in case my main drive was "too fast for me" (10,000). No dice. (And I'm now really sick of hitting Shift-F12.
![Wink :wink:](./images/smilies/icon_wink.gif)
Sorry for delay in coming back in here...
I've just reproduced easily, on a completely different machine - XP Pro SP3 32-bit. x2 pro version 2.0.0.1
Using the aforementioned switches /M /N /P, I launched x2, picked a file I know is not being accessed (it's a few months old), pressed shift-F12, ticked the 'created on' box, clicked 'now' button, clicked 'OK' button.
Immediately pressed shift-F12, time IS updated to 'now', created box is still ticked. Clicked 'now' button (saw time incremented 1 second) then clicked 'OK' button.
Immediately pressed shift-F12, time is NOT updated. Created box is still ticked. Clicked 'now' button (saw time incremented 2 seconds) then clicked 'OK' button.
Immediately pressed shift-F12, time is NOT updated. Created box is still ticked. Clicked 'now' button (saw time incremented 3 seconds) then clicked 'OK' button.
Immediately pressed shift-F12, time IS updated but to 1 second earlier than last update request. Created box is still ticked. Clicked 'now' button (saw time incremented 4 seconds) then clicked 'OK' button.
Crash.
I've sent the report.
--appyface
I've just reproduced easily, on a completely different machine - XP Pro SP3 32-bit. x2 pro version 2.0.0.1
Using the aforementioned switches /M /N /P, I launched x2, picked a file I know is not being accessed (it's a few months old), pressed shift-F12, ticked the 'created on' box, clicked 'now' button, clicked 'OK' button.
Immediately pressed shift-F12, time IS updated to 'now', created box is still ticked. Clicked 'now' button (saw time incremented 1 second) then clicked 'OK' button.
Immediately pressed shift-F12, time is NOT updated. Created box is still ticked. Clicked 'now' button (saw time incremented 2 seconds) then clicked 'OK' button.
Immediately pressed shift-F12, time is NOT updated. Created box is still ticked. Clicked 'now' button (saw time incremented 3 seconds) then clicked 'OK' button.
Immediately pressed shift-F12, time IS updated but to 1 second earlier than last update request. Created box is still ticked. Clicked 'now' button (saw time incremented 4 seconds) then clicked 'OK' button.
Crash.
I've sent the report.
--appyface
@nikos "extreme testing"? x2 will crash under very normal circumstances for me, tested now on four different machines with three different operating systems. You wanted a crash report so I did my best to get one as quickly as possible for you -- and you just write that off?
And what about not setting the time correctly? Are you writing that off too?
And what about not setting the time correctly? Are you writing that off too?