file size

open the file, seek to end, the get current file position. How to do that depends on C or C++. There are also other ways, such as stat(), win32 api GetFileSize(), and others.

>open the file, seek to end, the get current file position
That's only guaranteed to be meaningful on files opened with a binary orientation. Even then there's a possibility that the size may be inaccurate. The only portable way to determine the working size of a file is to open the file and read it, from beginning to end.

>oThe only portable way to determine the working size of a file is to open the file and read it, from beginning to end.

bullpucky! prove it by example. use of standard library file i/o functions are guarenteed by the language to be portable across platforms that support them. Open the file in binary mode and reading the file from beginning to end in MS-Windows will result same file size as returned by moving the file pointer to end-of-file and getting the file position. Open the file in text mode and reading file file will result in incorrect file size, but setting file pointer to end-of-file will result in the same file size that is returned when the file is opened in binary mode.

Text and binary mode opens are only relevant on MS-DOS/MS-Windows platforms. Other platforms result in identical reads/writes.

>use of standard library file i/o functions are guarenteed by the
>language to be portable across platforms that support them.
And conveniently enough the standard clearly states that arbitrary seeking on a text file is undefined.

>reading the file from beginning to end in MS-Windows will result
>in incorrect file size if the file is opened in text mode.
Perhaps if you want a byte count, but more commonly a character count is what people want. And if they want a byte count, they open the file as binary. So I say again, with complete confidence: The only way to portably get the size of a file is to read it from beginning to end and count what you're looking for.

>reading the file from beginning to end in MS-Windows will result
>in incorrect file size if the file is opened in text mode.
Perhaps if you want a byte count, but more commonly a character count is what people want. And if they want a byte count, they open the file as binary. So I say again, with complete confidence: The only way to portably get the size of a file is to read it from beginning to end and count what you're looking for.

Why do you assume you can read people's minds? The guy said he wants the file size, not the count of the number of characters in the file. If you want the character count they you are right -- the entire file has to be read. But that is not what "file size" means.

>Why do you assume you can read people's minds?
I don't assume. That's why I corrected your assumption that an arbitrary seek would work.

>But that is not what "file size" means.
Hypocricy is unbecoming. If you don't see it, allow me to explain. You have no idea what the OP means by "total size of file", and neither do I. The two most likely interpretations are byte count and character count. You assumed byte count, but I didn't assume either and offered a portable solution that worked for both.

google for "definition of file size" and your definition is not included

http://www.google.com/search?hl=en&lr=&oi=defmore&defl=en&q=define:File+size

The amount of space that a file takes up when stored on disk. File size is usally measured in bytes, kilobytes (K), megabytes (MB) or gigabytes (GB).
www.bized.ac.uk/educators/16-19/business/marketing/lesson/sup_glossary.htm

>google for "definition of file size" and your definition is not included
Clearly you're not in the right frame of mind to see reason, so I'll waste no more time with you. To keep the thread clean for relevant discussion, please direct any further off-topic comments to my private message box.

To keep the thread clean for relevant discussion, please direct any further off-topic comments to my private message box.

Peace :lol:

FWIW -

opening an MS-DOS text file (FAT16) in binary mode doesn't necessarily work as described above. The reason is that the reported size of the file by the filesystem is not the same as the length of the data in the file - because text files in MS-DOS end with ASCII 26, but the filesystem actually has more space allocated to the file. Binary access reads past the ASCII 26 - unless you know ahead of time that CTRL/Z ends the file. Which is not a "universal" approach IMO. YMMV.

IMO the clear intent of file size is knowing how much data is the file, for this kind of question, not necessarily how many sectors are allocated but not used.

If memory serves, stat() on these systems - as in TURBO C - has the samrts to deal with this. Does anyone know definitively?

Yes, the size of the file does not necessarily reflect the amount of data a program has actually stored in it -- there are win32 api functions that can increase the file size to an arbitrary size without doing any writes at all. I don't know if *nix or MAC has similar functions.

UNIX does - and you can create files with "holes" in them - literally.
In other words, a block (say 512 bytes) then a hole which uses ~twenty bytes but actually is say ten blocks of ASCII nul, then another block of data.

When this file is created it reports a file size of 1044 bytes or something close. When the identical file is restored from backup it creates a file 5120 + 1024 bytes long. 5120 bytes longer than it started. Backup sees the hole and creates it in the file, as it is "supposed" to be. stat() always reports it's size correctly - before or after.

All of this is merely filesystem stuff -DOS or UNIX or FAT32 or NTFS nonsense. Not really C.

If you are on a POSIX compliant system (Linux, UNIX, et al.) you can use stat() to get all sorts of interesting information about a file. Note that this is not part of the ANSI C standard, and as such is non-portable.