ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

"File Size" Not Increasing As It Should Be

<< < (3/4) > >>

KodeZwerg:
TotalCommander watches in realtime all changes.
The problem is how windows works or better how you application that write something work.

The filesystem will get a notification message to update explorer (and others) just after a file is written / the application that do writing have to close the filehandle. Some applications send several messages to explorer after they wrote a block of data.

The standard would be:
When an application create a file to write something, and pumps in data, all is done in your windows and hdd cache.
If you want to see every little change in realtime you should disable all caches.
You will notice that your hdd activity will increase by a lot of more disk reading and writing.
All become slower due to this but you will be able to see in realtime how a file grow.

x16wda:
stat.exe %s filename will show the correct size if it is available, sometimes it isn't. I don't see it included in coreutils, but I thought it came with unxutils Windows port. Can't find it with a quickie search though.

nkormanik:
Nirsoft FolderChangesView seems the best option so far.

However, even this doesn't show the actual file size.

Here is an email I just wrote to Nirsoft:

Enhancement Request -- FolderChangesView

Please incorporate a ‘button’ or ‘menu offering’ to really refresh all the present files shown.

For some reason the existing refresh does not really update file sizes, at least not when files are still being written to.

A process I have running keeps adding to a particular file.  Only way to see the increased real file size is to bring up ‘File Properties,’ one individual file at a time.

Far, far better to have a means to refresh all files shown, really refreshing them, showing true file sizes.

Thanks!

Nicholas Kormanik

x16wda:
So I verified stat.exe is actually in coreutils 5.3 at least even though it isn't mentioned in the list: gnu coreutils

Try using this periodically during your process and see if it doesn't give you a more up to date value:  stat.exe -c %s full-filename.here

Or you can just do 'stat filename' and you'll see the full display.

KodeZwerg:
Aslong a file aint written you do not see much changes. It is all in cache.
There are possibilies for programmers to update explorer.exe, if they dont use them you just have to wait...
In some of my own copy-routines for example you will instant see final filesize, due how i deal with it.

Why not just look your copy-progress to see how much data you received?

To explain a bit more why you never be able to have such thing under your control...
Imagine this situation, it is a practical way to quick save multithreaded:
 - Copy-Program begin
 - progress is more than one thread
 - progress create first of all the final filesize
 - prograss create individual thread that write to different offsets a specific amount of data
 - now tell me how would you ever be able to see how many bytes are written with explorer.exe or stat.exe or whateverelse.exe
 - solution: watch programs progress and forget about windows

next sample:
 - Copy-Program begin
 - progress is one thread
 - progress read file a) into memory
 - progress write memory to file b)
 - aslong routine is writing, no external can access it to get proper information
 - you can try readout by overriding, this may end in a corrupted file due that action
 - solution: watch programs progress and forget about windows

good programmed routines work like this:
 - Copy-Program begin
 - progress read chunk(s)
 - progress write chunk(s)
 - progress update explorer.exe that it has written some more chunks to file
 - only in this situation you are able to get proper information
 - to force this situation, you need to disable all caches

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version