Change file create and modified time not working

appyface · Post by **appyface** » 2011 Oct 08, 14:38

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."

Kilmatead · Post by **Kilmatead** » 2011 Oct 08, 17:20

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.

fgagnon · Post by **fgagnon** » 2011 Oct 08, 17:31

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).

Kilmatead · Post by **Kilmatead** » 2011 Oct 08, 17:38

fgagnon wrote:(LSB would be approximately 2.64 seconds)

Nicely computed! :D (For the less technical in the audience, LSB is Least Significant Bit.)

appyface · Post by **appyface** » 2011 Oct 08, 20:18

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

fgagnon · Post by **fgagnon** » 2011 Oct 08, 20:30

Those switches should have no bearing on the issue.
...
FWIW, I use 'em too.

Post by **nikos** » 2011 Oct 09, 07:29

for all intents and purposes you won't get better accuracy than 2 seconds for file times with xplorer2/windows. 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

Kilmatead · Post by **Kilmatead** » 2011 Oct 09, 08:59

nikos wrote:for all intents and purposes you won't get better accuracy than 2 seconds for file times with xplorer2/windows.

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?

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)

Thracx · Post by **Thracx** » 2011 Oct 10, 14:42

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

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, 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

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.

I believe you need to attempt to change the date value from initial value X, to value Y, but before value Y is committed, you need to issue a change from value X to value Z. The same behavior can be observed via using the 'Created on:' field, but I have not tested whether or not the other attribute fields can cause this.

Kilmatead · Post by **Kilmatead** » 2011 Oct 10, 18:05

Thracx wrote:This is a known crash-bug in X², see this post from May.

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.

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.

)

appyface · Post by **appyface** » 2011 Oct 17, 19:19

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

Post by **nikos** » 2011 Oct 18, 08:58

I see how this can crash xplorer2 in extreme testing circumstances like yours. However as this won't affect normal xplorer2 users i'm prepared to let it go

Kilmatead · Post by **Kilmatead** » 2011 Oct 18, 09:09

Somehow I don't think they'll like that answer. Interesting though, that I can't get it to crash no matter how extreme I try to.

appyface · Post by **appyface** » 2011 Oct 18, 10:45

@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?

Post by **nikos** » 2011 Oct 18, 15:05

when you set the file time 10 times in a row for the same file that's what i consider extreme testing! And as I said you cannot set file times to anything but a 2-second granularity

thank you for your crash report but i don't risk changing a lot of code unless there is a clear problem or benefit