here is the code snippet
HANDLE hFile = CreateFile( indir, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING , FILE_FLAG_BACKUP_SEMANTICS, NULL );
if (SUCCEEDED(hFile))
{
BY_HANDLE_FILE_INFORMATION lpFileInformation;
GetFileInformationByHandle(hFile, &lpFileInformation);
LARGE_INTEGER filesize;
GetFileSizeEx(hFile, &filesize);
DWORD bytesize= (lpFileInformation.nFileSizeHigh* (MAXDWORD+1)) +
lpFileInformation.nFileSizeLow;
double val = floor( (double)bytesize/(double)1048576*(double)100000 ) /
(double)100000;
}
Under win32, a directory is not a file.
> HANDLE hFile = CreateFile( indir, GENERIC_READ, FILE_SHARE_READ, NULL,
> OPEN_EXISTING , FILE_FLAG_BACKUP_SEMANTICS, NULL );
> if (SUCCEEDED(hFile))
The SUCCEEDED macro is not correct here. Please read the documentation for
CreateFile and check against the error returnvalue mentioned there.
> LARGE_INTEGER filesize;
> GetFileSizeEx(hFile, &filesize);
How about checking for errors here? Again, see the documentation for
GetFileSizeEx() to find out how errors are signaled.
Sloppy programming gives sloppy results, so far no surprises...
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
There's none.
http://blogs.msdn.com/oldnewthing/archive/2009/02/17/9426787.aspx
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
It's Bullshit.
There are methods faster than FindFirstFile() with NAPI or COM
How about not relying on having that size up front? What do you need that
size for? If you end up iterating over the elements anyway, you should use
FFF/FNF and use the immediate element right there, not store it away
somewhere.
...which are?
Seriously, did you even read that blog entry? I'd say it pretty well
explains why this info shouldn't be expected to be there.
Other than that, one way to speed up counting files is to actually count
them once and then use that cached value, updating it via filesystem change
notification hooks when necessary. If that is a good idea is questionable
though.
"Ulrich Eckhardt" <eckh...@satorlaser.com> wrote in message
news:shvdj6-...@satorlaser.homedns.org...
> Sachin wrote:
>> hi I was trying to get size of a directory using GetFileSize ()
>> but it always return 0 .
>> Cant we use GetFileSize for Directory ?
No. At least it will not give you the recursive total size you are looking
for, perhaps the size of the directory index entries themselves and perhaps
not even that.
>
> Under win32, a directory is not a file.
CreateFile documentation says:
Creates or opens a file or I/O device. The most commonly used I/O devices
are as follows: file, file stream, directory, physical disk, volume, console
buffer, tape drive, communications resource, mailslot, and pipe.
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
And many other "File" functions treat files and directories equally, like
FindFirstFile/FindNextFile.
on Ulrich Eckhardt
>. What you said is perfectly logical. I agreed.
My primary requirement is finding out how many Files my tools will be
copying / what is the total size of data my tool will copy.
To give you all general idea , my tools takes list of files / folders
to copy from a XML file. and iterate inside the given directory and copy the
files to target location.
While copying it has to process the data so i cant simply use
ShFileOperation
And when the files / directories is huge then the program just keep
progressing without the end user knowing the status
So i was thinking of precalculating the total size and number of files the
tool is going to process.
and use MFC Progress bar to indicate the progress
any idea how to achive this efficiently ?
>> Igor Tandetnik
The article was really helpful and informative thanks for sharing this.
sachin
Use two loops, one just enumerating the directory tree and the other
processing/copying it. However, run both loops in the background, i.e. in
separate threads. Then, from the one that enumerates, you take the number
of dirs/files to process. From the other, you take the number of processed
items. Using a timer, you then update the progress bar with the data from
the two threads.
Alternatively, you could do the two steps in one thread, telling the user
about the progress of both steps separately.
Thanks all for your help
Thanks Ulrich .
Sachin
does Oprrating system uses some cache file to display the file count and
size of a directory ?
because i have observed it to be very fast as compared to a program which
does FFF and FNF
sachin