Recent Posts

1

Beta Releases / Re: 15.2 Beta 3078

« Last post by Ulfhednar on March 28, 2025, 12:18:39 »

Thanks for the update Mathias.
Unfortunately some of my context items have now been lost.  They still exist in Explorer but not in MC i.e. - the base item remains but the submenu is a blank tab. 
Tried a reinstall - no change.
Can I manually restore these? Regedit?

2

Support and Feedback / Re: Foldersize wrong if folder contains very long paths

« Last post by StefanH on March 28, 2025, 12:02:08 »

I'm not able to test it at the moment..

But to get this right.
Folder sizing show wrong size on network path that are extra long ( Longer then 255char ) ?  => yes

Long path support is supported. but it might fail on some places. since not all windows API support it.
I know it worked before. But folder sizing has been reworked since then.
But it can most likely be fixed if it is an issue. I will check tomorrow

3

Support and Feedback / Re: Foldersize wrong if folder contains very long paths

« Last post by Mathias (Author) on March 28, 2025, 11:12:32 »

I'm not able to test it at the moment..

But to get this right.
Folder sizing show wrong size on network path that are extra long ( Longer then 255char ) ?

Long path support is supported. but it might fail on some places. since not all windows API support it.
I know it worked before. But folder sizing has been reworked since then.
But it can most likely be fixed if it is an issue. I will check tomorrow

4

Support and Feedback / Re: Foldersize wrong if folder contains very long paths

« Last post by Matthias515566 on March 28, 2025, 10:01:00 »

Your screenshots do show the correct directory size, though.

5

Support and Feedback / Foldersize wrong if folder contains very long paths

« Last post by StefanH on March 28, 2025, 08:19:41 »

I have to copy a folder from the network to an other location and to verify if everthing is ok I compare the foldersize from source and target. I'm wondering that it differ and it becomes clear that this is due to very long pathes of the source dir. Getting the folder size of the source with robocopy shows the correct size. See screenshot (right = source, left = target). I'm usiing Multicommander 15.2 on Windows11.
If I show the properties of the source folder with the file explorer it shows the correct size (like the result fo the robocopy).

Any ideas if this could be fixed by whatever setting in MC? It seems that the support for long paths isn't implemented so far.

6

Feature Requests and Suggestions / Re: How to synchronize Panels

« Last post by Johannes-in-Berlin on March 27, 2025, 18:56:10 »

Thank you!! 

7

Support and Feedback / Re: time display

« Last post by JeanneMarie on March 27, 2025, 18:38:57 »

If you really need exact time always. then go for showing time in UTC.

Meaning DE-select that "adjust datetime for DST" checkbox? That's what I've been thinking (along with thinking I'm happy this is not hugely important to me).

But serious thanks again. I feel so knowledgeable!

 

8

Support and Feedback / Re: time display

« Last post by Mathias (Author) on March 27, 2025, 15:41:58 »

The date/time is the same. A Timestamp that a file has in NTFS is the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 (UTC).
So Time and Date are not set separate. it is one very big value.

So a step further: When I now change the time on that Jan. 5 file to 2:47p, the "correct" time of 1:47 displays (the time I entered).

But what happens when we go on standard time? I think it will say the wrong time (2:47).

And therefore, I think the rule is... when I enter a new time, the current regime (DST vs. Standard) will control rather than the date on the file.

"Adjust for DST" is only for display in filelist.
The problem is that local time is used when settings the timestamp. Sometimes you might want to use the date from the specified timestamp.
Problem is if it should use date from the timestamp to set. and then viewing it.. it would be wrong if DST did not match with local.
Maybe a checkbox in the Set filetime dialog that lets you decided.. but then we got more advanced option that people will not understand.

The problem is no matter what you do there are senarios where it shows wrong. If you really need exact time always. then go for showing time in UTC.

DST/Timezone are tricky.. there are even special timestamp ranges in local time that is impossible to convert to UTC
(When you switch the clock back.. at 02:59 -> 02:00   that day. the local time is 02:00 -> 02:59 twice, )

9

Feature Requests and Suggestions / Re: How to synchronize Panels

« Last post by Mathias (Author) on March 27, 2025, 15:09:43 »

Ctrl+.  (dot) - Will make the opposite panel go to same location as current panel

10

Support and Feedback / Re: time display

« Last post by JeanneMarie on March 27, 2025, 14:17:35 »

First, FYI, there was never a problem with the dates. The issue has only been the time.

But wow, yes. When I changed this date and time (two days ago on the Jan. 5 file), we had already entered DST (a couple of weeks earlier).
And yes, when I uncheck "adjust datetime for DST"  I get the same time as the change dialog displays (the time I entered).

So a step further: When I now change the time on that Jan. 5 file to 2:47p, the "correct" time of 1:47 displays (the time I entered).

But what happens when we go on standard time? I think it will say the wrong time (2:47).

And therefore, I think the rule is... when I enter a new time, the current regime (DST vs. Standard) will control rather than the date on the file.

It may be true that the experts instantly recall that the file system uses UTC, but if nothing else, this deserves some mention in the documentation--specifically with respect to this dialog (change properties). If it's there, mea culpa, I missed it.

Gosh, with all the discussion of ditching this changing of regimes twice a year, here's another good reason.

Thanks for so much help in clarifying what's happening. That is way more than half the battle,
Jeanne