Reread source command does not update file size

[browny]

I noticed it when watching progress of downloads in Firefox.
Firefox stores data in .part file, which increases it's size in the process (on completion that file would be renamed to the proper name by dropping .part suffix).
So I start a download and moved cursor in TC's panel to the .part file.

Free space on drive above file panel is updated when Reread source command would be executed (Ctrl-R, button, Show -> Reread source menu item).
But file's size below file panel stays unchanged.
The size might get updated by switching to another application and back to TC window.

Windows 10 32-bit, TC 9.0 b4.
Beta 3 behaved the same way.

[ghisler(Author)]

This is actually a misfeature of the NTFS file system: File attributes like the size and timestamp are only updated in the directory when the file is CLOSED. You can force that by opening and closing the file yourself (if the file isn't locked by the other process). Try e.g. F3 or Alt+Enter on the file, that should instantly update the size when watching for directory changes.

[browny]

This is actually a misfeature of the NTFS file system: File attributes like the size and timestamp are only updated in the directory when the file is CLOSED. You can force that by opening and closing the file yourself (if the file isn't locked by the other process). Try e.g. F3 or Alt+Enter on the file, that should instantly update the size when watching for directory changes.

It seems to be more complicated.
Today I started download in Firefox, and watched Far and Explorer (TC was not installed there). Application windows were arranged so that size could be seen in all three programs; and by clicking on captions it was possible to switch between applications.

Far is known to update it's F3 viewer in real time, so it could be expected that file size might be updated too. It does in a way, but not trivially.

Ctrl-R in Far does not update file size - just as it was with TC. The size is not updated by itself too while download is in progress.
Switching between Far and Explorer does nothing.
F5 in Explorer with noticeable delay (1-2 seconds) properly updates file size; after that Far also updates displayed size.
However, switching to Firefox updates size in Explorer and in Far without any extra key pressed.

[ghisler(Author)]

F5 in Explorer with noticeable delay (1-2 seconds) properly updates file size

That's interesting, apparently Explorer calls some unknown function causing NTFS to flush the changed size to the directory. If anyone knows what function that is, then I will gladly add it to Total Commander too. As you can see Far has the same problem as TC.

If you enable watching directory changes in TC Configuration - Options - Refresh, it will surely also refresh automatically when you press F5 in Explorer...

[MVV]

Maybe Explorer opens all files in a dir (and this tooks 1-2 seconds)?

[browny]

Small research in the net brought this: Why is the file size reported incorrectly for files that are still being written to?

[MVV]

So there are no any magic, only opening and closing a file may help... if only TC could know which file has stale attributes in its directory...

[browny]

if only TC could know which file has stale attributes in its directory...

The one under the cursor, no?

[MVV]

I think it is easy to write a tool that will open-close focused or selected files by hotkey:)

[umbra]

cm_ListInternalOnly + ESC always does the trick for me

[browny]

cm_ListInternalOnly + ESC always does the trick for me

Smart idea.
Just as suggested in the article: opening and closing file should update directory data.

[MVV]

Something like this should work from buttonbar button:

Code: Select all

Command: powershell.exe
Parameters: -c "ls | ? { $_ -is [IO.FileInfo] -and $_.LastWriteTime -gt ([DateTime]::Now.AddDays(-1)) } | %% { [IO.File]::Open($_.FullName, [IO.FileMode]::Open, [IO.FileAccess]::Read, [IO.FileShare]::ReadWrite).Close(); }"

This command should open and close all files in current folder which were modified during last day. Perhaps it reguires playing with some file open parameters...

[ghisler(Author)]

Maybe the Explorer is reloading the file icon? Is it an EXE file or other file with individual icon?

[HolgerK]

This is an old bug which can easily avoided by turning on
"Configuration-> Options -> Icons: [x] Show overlay Icons, e.g. for links"
Sea also: German thread from 2013

Regards
Holger

[MVV]

I don't think it is a bug, it is a normal NTFS behaviour. Enabling overlay icons in such case is more a workaround than a fix.