Unpacking to a protected Folder works not because the Adminmode go not on

[Matthias515566]

I tried to unpack the Software FontViewOk directly in the program files folder, but this did not work. MC do just nothing, say nothing when run not anyway in admin mode.

Have somebody testet the daylightsavings-problem when run MC permanent as admin?

[AlanJB]

I tried to unpack the Software FontViewOk directly in the program files folder, but this did not work. MC do just nothing, say nothing when run not anyway in admin mode.

I cannot help with this because I use WinZip & 7Zip.

Have somebody testet the daylightsavings-problem when run MC permanent as admin?

What is the "daylightsavings-problem"?  I run MC permanently in Admin mode and I have no problems...

[Matthias515566]

What is the "daylightsavings-problem"?  I run MC permanently in Admin mode and I have no problems

Sometimes (i guess now in the summer time) will be the modify dates 1 hour wrong. This is the daylightsavings problem. And this is only when run as administrator. The same in FC and FC have a synchronizer, this can cause that a newer file be overwritten by a older file. MC have no syncronizer, it is not so matter, but when all dates a hour wrong und you synchronize later with another software you can overwrite a newer file again. This is only when you synchronizing the same within a hour. The Android Taschenrechner destroy anyway the Modify Date.

[AlanJB]

OK.  I understand the problem now.  But I have never seen it happen.

Maybe because I user"Explorer Style" and not "Commander Style".

[Mathias (Author)]

I will look into unpack and check if it is possible

What is the "daylightsavings-problem"?  I run MC permanently in Admin mode and I have no problems

Sometimes (i guess now in the summer time) will be the modify dates 1 hour wrong. This is the daylightsavings problem. And this is only when run as administrator. The same in FC and FC have a synchronizer, this can cause that a newer file be overwritten by a older file. MC have no syncronizer, it is not so matter, but when all dates a hour wrong und you synchronize later with another software you can overwrite a newer file again. This is only when you synchronizing the same within a hour. The Android Taschenrechner destroy anyway the Modify Date.

I do not think it has to do with Admin or not, all file dates in windows are UTC. however in a zip all files date are local time (without a reference to TZ). And sometimes a date might be converted incorrect becuse it is impossible to know

If you see another dateissue you need to send an example.

[Matthias515566]

When the EU rstop the daylightsavings, then we have no longer the daylightsavings-problem.

Today i made some daylightsavingsproblem-tests.  In the Summer time the problem do not exist. Any file fill be copied with the correct date. In the winter time, all files will have a wrong date after copy or move operation.

better i make a thread in winter - or waiting until the EU removed this daylightsavings.

[Mathias (Author)]

it depends on how you want to show it.
and it also depends on what FileSystem the file are stored on or what archive format the files are stored in. some store filetime in UTC, some store in LocalTime.. some store in LocalTime but with TZ info
standard zip only have a FileTime, that is local, but with no reference, some without,
The DST issue is a problem is always going to be a mess. and some special time periods during the switch can be impossible to solve