Visual Basic - Read file properties

Author

Read file properties

RB Smissaert

2006-07-02, 6:55 pm

Is there a way (other than with FileDateTime etc.) to read the file
properties directly from a file?
Or is there a way to read all the file data (header data etc. included), not
just the data that can be
read when the file is opened by it's default program?

I thought that this would do it:

Function ReadFileBinary(strFile As String) As Variant

Dim hFile As Long
Dim btArray() As Byte

ReDim btArray(1 To FileLen(strFile))

hFile = FreeFile

Open strFile For Binary As #hFile
Get #hFile, 1, btArray
Close hFile

ReadFileBinary = btArray

End Function

But it doesn't as when I run the above and then alter the file date (with
the API) and then read it again
it still shows exactly the same.
I am sure I am overlooking something simple here, but some Googling didn't
show me how to do this.

RBS

Larry Serflaten

2006-07-02, 6:55 pm

"RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote
> Is there a way (other than with FileDateTime etc.) to read the file
> properties directly from a file?
<...>
> I thought that this would do it:
>
> Function ReadFileBinary(strFile As String) As Variant
<...>
> End Function
>
> But it doesn't as when I run the above and then alter the file date (with
> the API) and then read it again
> it still shows exactly the same.
> I am sure I am overlooking something simple here, but some Googling didn't
> show me how to do this.

Are you looking for the file properties, or the file contents?

What you've show gets all of a file's contents, and none of its
properties. See if this helps to get more file info....

http://www.tutorialized.com/tutoria...Basic-code/5285

LFS

Mike D Sutton

2006-07-02, 6:55 pm

> Is there a way (other than with FileDateTime etc.) to read the file properties directly from a file?
> Or is there a way to read all the file data (header data etc. included), not just the data that can be
> read when the file is opened by it's default program?
>
> I thought that this would do it:
>
> Function ReadFileBinary(strFile As String) As Variant
>
> Dim hFile As Long
> Dim btArray() As Byte
>
> ReDim btArray(1 To FileLen(strFile))
>
> hFile = FreeFile
>
> Open strFile For Binary As #hFile
> Get #hFile, 1, btArray
> Close hFile
>
> ReadFileBinary = btArray
>
> End Function
>
> But it doesn't as when I run the above and then alter the file date (with the API) and then read it again
> it still shows exactly the same.
> I am sure I am overlooking something simple here, but some Googling didn't show me how to do this.

Have a look at the GetFileTime() API call:
http://groups.google.co.uk/group/mi...7fca39a9348dd7c
By the looks of it you're after the last access time, so if you're using the above example the change the following
line:

'***
If (GetFileTime(hFile, CreateTime, ByVal 0&, ByVal 0&)) Then _
'***

To this:

'***
If (GetFileTime(hFile, ByVal 0&, CreateTime, ByVal 0&)) Then _
'***

Obviously it would also make sense to change the function name and some of the variables, however I'll leave that up to
you.
Hope this helps,

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

RB Smissaert

2006-07-02, 6:55 pm

I am looking for file properties, but not the standard properties such as
file date/time, file size etc.
This only came about after I tried to answer a question in the
excel.programming group:

---------------------------------------------------------------------------------------------------
I have some photos and I'm creating a sheet that inventories my images.
I am inserting a photo thumbnail on the sheet and I would like excel to
read the (ITCP) data from the image such as date it was taken, Fstop,
focal length, etc. and automatically fill in the corresponding fields.

Does excel have the capability to retrieve that information from the
photo?
---------------------------------------------------------------------------------------------------

I thought that the code I posted would show all the file data, so both
properties and contents, but
I realize now that this is not the case and that it only will show contents.

Not sure if the code in the URL you posted will get information as above.

RBS

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:udNF4wfnGHA.3440@TK2MSFTNGP04.phx.gbl...
>
> "RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote
> <...>
> <...>
>
> Are you looking for the file properties, or the file contents?
>
> What you've show gets all of a file's contents, and none of its
> properties. See if this helps to get more file info....
>
> http://www.tutorialized.com/tutoria...Basic-code/5285
>
> LFS
>
>

RB Smissaert

2006-07-02, 6:55 pm

It's not that.
I am interested to see all the file related data, the contents plus any
properties, basically the whole file,
header, trailer, whatever.
I thought that a hex editor would show all this, but it doesn't seem so
after looking at the Cygnus editor.

RBS

"Mike D Sutton" <EDais@mvps.org> wrote in message
news:OqVT45fnGHA.1332@TK2MSFTNGP05.phx.gbl...
>
> Have a look at the GetFileTime() API call:
> http://groups.google.co.uk/group/mi...7fca39a9348dd7c
> By the looks of it you're after the last access time, so if you're using
> the above example the change the following line:
>
> '***
> If (GetFileTime(hFile, CreateTime, ByVal 0&, ByVal 0&)) Then _
> '***
>
> To this:
>
> '***
> If (GetFileTime(hFile, ByVal 0&, CreateTime, ByVal 0&)) Then _
> '***
>
> Obviously it would also make sense to change the function name and some of
> the variables, however I'll leave that up to you.
> Hope this helps,
>
> Mike
>
>
> - Microsoft Visual Basic MVP -
> E-Mail: EDais@mvps.org
> WWW: Http://EDais.mvps.org/
>

RB Smissaert

2006-07-02, 6:55 pm

Would the FindFirstFile API show any such properties?
Although looking at:

Private Type WIN32_FIND_DATA
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * MAX_PATH
cAlternate As String * 14
End Type

It suggests not as there are only 2 elements (dwReserved0 and dwReserved1)
that
could do this.

RBS

"RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote in message
news:uWlTE$fnGHA.780@TK2MSFTNGP04.phx.gbl...
>I am looking for file properties, but not the standard properties such as
>file date/time, file size etc.
> This only came about after I tried to answer a question in the
> excel.programming group:
>
> ---------------------------------------------------------------------------------------------------
> I have some photos and I'm creating a sheet that inventories my images.
> I am inserting a photo thumbnail on the sheet and I would like excel to
> read the (ITCP) data from the image such as date it was taken, Fstop,
> focal length, etc. and automatically fill in the corresponding fields.
>
> Does excel have the capability to retrieve that information from the
> photo?
> ---------------------------------------------------------------------------------------------------
>
> I thought that the code I posted would show all the file data, so both
> properties and contents, but
> I realize now that this is not the case and that it only will show
> contents.
>
> Not sure if the code in the URL you posted will get information as above.
>
> RBS
>
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> news:udNF4wfnGHA.3440@TK2MSFTNGP04.phx.gbl...
>

Larry Serflaten

2006-07-02, 6:55 pm

"RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote

> I have some photos and I'm creating a sheet that inventories my images.
> I am inserting a photo thumbnail on the sheet and I would like excel to
> read the (ITCP) data from the image such as date it was taken, Fstop,
> focal length, etc. and automatically fill in the corresponding fields.

What does ITCP stand for?

LFS

RB Smissaert

2006-07-02, 6:55 pm

I don't know, but maybe this question has already been answered in
public.excel.programming: reading data from thumnails.
I am not interested really in reading data from images, but just how to
get all data from any file in general. That is all data as how it is on the
HD,
not just the content of the file.
Can VB read all the bits of a file?

RBS

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:%237cwGmhnGHA.1204@TK2MSFTNGP04.phx.gbl...
>
> "RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote
>
>
> What does ITCP stand for?
>
> LFS
>
>

Mike D Sutton

2006-07-02, 6:55 pm

>I am looking for file properties, but not the standard properties such as file date/time, file size etc.
> This only came about after I tried to answer a question in the excel.programming group:
>
> ---------------------------------------------------------------------------------------------------
> I have some photos and I'm creating a sheet that inventories my images.
> I am inserting a photo thumbnail on the sheet and I would like excel to
> read the (ITCP) data from the image such as date it was taken, Fstop,
> focal length, etc. and automatically fill in the corresponding fields.
>
> Does excel have the capability to retrieve that information from the
> photo?
> ---------------------------------------------------------------------------------------------------
>
> I thought that the code I posted would show all the file data, so both properties and contents, but
> I realize now that this is not the case and that it only will show contents.

It sounds to me like what you're after is EXIF information, assuming you're images are stored as JPEG files. If not
then you're going to have to look at pulling the information back from the file headers yourself, you can grab the file
format specifications from www.wotsit.org and writing a simple parser to extract the relevant data isn't too bad at all.
I have some *Info classes on my site that extract various bits of information from different file formats, the JPEGInfo
class however only extracts data from the native JPEG tags, not the extended EXIF information, however you can easily
plug your own parser in at that point to parse that data.
You may also find this link to be useful if using GDI+ is an option for you:
http://www.vbaccelerator.com/home/v...ies/article.asp
Hope this helps,

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

RB Smissaert

2006-07-02, 6:55 pm

> pulling the information back from the file headers yourself

Now that is the point. How do I do that?

RBS

"Mike D Sutton" <EDais@mvps.org> wrote in message
news:%23D0Y3vinGHA.1604@TK2MSFTNGP03.phx.gbl...
>
> It sounds to me like what you're after is EXIF information, assuming
> you're images are stored as JPEG files. If not then you're going to have
> to look at pulling the information back from the file headers yourself,
> you can grab the file format specifications from www.wotsit.org and
> writing a simple parser to extract the relevant data isn't too bad at all.
> I have some *Info classes on my site that extract various bits of
> information from different file formats, the JPEGInfo class however only
> extracts data from the native JPEG tags, not the extended EXIF
> information, however you can easily plug your own parser in at that point
> to parse that data.
> You may also find this link to be useful if using GDI+ is an option for
> you:
> http://www.vbaccelerator.com/home/v...ies/article.asp
> Hope this helps,
>
> Mike
>
>
> - Microsoft Visual Basic MVP -
> E-Mail: EDais@mvps.org
> WWW: Http://EDais.mvps.org/
>

mayayana

2006-07-02, 9:55 pm

> > pulling the information back from the file headers yourself
>
> Now that is the point. How do I do that?
>
Someone posted a link for an EXIF class in just
the last couple of w

s. I don't have a link to
that posting, but you should be able to find it.

There are several categories of file info.
There's the basic "general" info.

Then there's
FileVersionInfo in PE files, which has its own data
format in the file's resource table.

Then there's EXIF data, which comes near the beginning
of the file. There are a large number of custom EXIF
categories, designated numerically. Any number of them
can be stored in the EXIF data. Microsoft's Summary info.
is one such section, but MS does things differently, storing
unicode while everyone else seems to store ASCII. Each
camera company, I think, also has their own numeric
category. I forget, offhand, exactly how it works, but there's
a sort of header format to the EXIF section, structured in
such a way that it's possible to search out and parse each
section. It's all detailed here:

http://www.media.mit.edu/pia/Resear...pview/exif.html

Aside from Microsoft's EXIF data, EXIF is generally
photo/camera info. saved by different digital cameras
in the EXIF section relating to the camera company.

IPTC (International Press Telecommunications Council) is
general info. IPTC is a standard created by the IPTC and
the Newspaper Association of America (NAA). It's designed
more to describe a photo, rather than to describe lighting,
f-stop, etc. IPTC typically includes title, description,
copyright, date, etc. IPTC has a different header from EXIF.

It all gets more confusing because most software does
not recognize both formats. PhotoShop and IrfanView, I
think, recognize both. But Windows XP does not recognize
IPTC. If you save Summary info. in XP you lose any IPTC
data. If you resave the jpg in other programs you may
lose one or both data sets (IPTC and/or EXIF).

Larry Serflaten

2006-07-03, 3:55 am

"mayayana" <mayaXXyana1a@mindXXspring.com> wrote
> I forget, offhand, exactly how it works, but there's
> a sort of header format to the EXIF section, structured in
> such a way that it's possible to search out and parse each
> section. It's all detailed here:
>
> http://www.media.mit.edu/pia/Resear...pview/exif.html

FWIW: That is the same document that will be found at
www.wotsit.org

LFS

R. MacDonald

2006-07-03, 3:55 am

Hello, RB,

The "OLE" file properties used on NTFS file systems can be retrieved
using DSOFile.dll but I've read something recently that led me to
believe that the JPEG information is handled differently. So in your
case maybe the link that Mike provides will be more relevant.

Here is another link for which I've seen a reference. I haven't looked
at it, but apparently it's an example in C#. Maybe you will be able to
get some ideas from it.

Cheers,
Randy

RB Smissaert wrote:
> I am looking for file properties, but not the standard properties such
> as file date/time, file size etc.
> This only came about after I tried to answer a question in the
> excel.programming group:
>
> ---------------------------------------------------------------------------------------------------
>
> I have some photos and I'm creating a sheet that inventories my images.
> I am inserting a photo thumbnail on the sheet and I would like excel to
> read the (ITCP) data from the image such as date it was taken, Fstop,
> focal length, etc. and automatically fill in the corresponding fields.
>
> Does excel have the capability to retrieve that information from the
> photo?
> ---------------------------------------------------------------------------------------------------
>
>
> I thought that the code I posted would show all the file data, so both
> properties and contents, but
> I realize now that this is not the case and that it only will show
> contents.
>
> Not sure if the code in the URL you posted will get information as above.
>
> RBS
>
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> news:udNF4wfnGHA.3440@TK2MSFTNGP04.phx.gbl...
>
>

Mike D Sutton

2006-07-03, 7:55 am

> > pulling the information back from the file headers yourself
>
> Now that is the point. How do I do that?

If you want to extract the data yourself rather than use a third party library, then as mentioned in my prior post you
need to have the format specification of the file type you're interested in. There are numerous ways of getting hold of
this, sites such as www.wotsit.org have information on many of the more common file formats, and failing that general
web searches often turn up something.
The other thing you'll need is a good hex editor with which you can pick apart the file and verify manually that what
you expect to be present is actually there. I use and recommend "Hex Workshop" (www.bpsoft.com) however there are many
good hex editors around so pick one you're comfortable with (One nice thing about HW that I'd not seen in other editors
at the time (don't know if this is still the case) is its structure support, where you can define file structures and
map them within a file, very handy for a number of formats.)
Another thing to watch out for when writing your file parser is whether the file uses Little (Intel) or Big (Motorola)
byte order. VB uses little-endian byte order for all its types, so if you're working with a format that stores its data
in big-endian format then you would need to swap the byte order to properly interpret the values. Here's a couple of
routines for converting integer types:

'***
Private Function FlipWord(ByVal inWord As Integer) As Integer ' Endian swap on Word
FlipWord = ((inWord And &H7F) * &H100) Or (((inWord And &HFF00) \ &H100) And &HFF)
If (inWord And &H80) Then FlipWord = FlipWord Or &H8000
End Function

Private Function FlipDWord(ByVal inDWord As Long) As Long
FlipDWord = _
(((inDWord And &HFF000000) \ &H1000000) And &HFF&) Or _
((inDWord And &HFF0000) \ &H100&) Or _
((inDWord And &HFF00&) * &H100&) Or _
((inDWord And &H7F&) * &H1000000) ' Endian swap on DWord
If (inDWord And &H80&) Then FlipDWord = FlipDWord Or &H80000000
End Function
'***

And an old post demonstrating how to perform a endian flip on any type, specifically on floats and doubles:
http://groups.google.co.uk/group/mi...df197051262c15b

Also, many formats use unsigned values and again since all VB's integer types are signed these again require conversion
to be interpreted properly in VB. Here's another old post with some code in the convert between signed and unsigned
integer values:
http://groups.google.co.uk/group/mi...3d78be2b514d0e1

Finally, some formats these days support very large files and as such require very large numbers to handle offsets and
such correctly. In these cases an 8-byte integer type (QWord) is used, but again since VB has no native support for
these values, they must be converted to be used correctly. Here's another old post with some functions in for working
with them should you need it:
http://groups.google.co.uk/group/mi...47fea5d3bcb6ce0

When writing your parser, always open the file in binary mode and unless you're working with textual data, never use
strings for reading data in or writing data out to avoid ASCII <-> UNICODE and locale issues. Your other option is to
use an API based file parser which is slightly more complex but gives you slightly more efficient data handling when
working with large chunks of data, and is essential when working with large (>2 GB) files since VB's file handling
routines will not cope with this.

Armed with all that you should be picking apart files in no time, however if you have any more specific questions then
post back here.
Hope this helps,

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

RB Smissaert

2006-07-03, 7:55 am

Thanks for that.
Is there a generic way to read file headers, without knowing anything about
the structure of the file?
Or is it not possible to determine what/where the header is without knowing
the file structure?
To be honest I don't really know exactly what a file header is precisely.

RBS

"Mike D Sutton" <EDais@mvps.org> wrote in message
news:O%23pIdBpnGHA.4864@TK2MSFTNGP04.phx.gbl...
>
> If you want to extract the data yourself rather than use a third party
> library, then as mentioned in my prior post you need to have the format
> specification of the file type you're interested in. There are numerous
> ways of getting hold of this, sites such as www.wotsit.org have
> information on many of the more common file formats, and failing that
> general web searches often turn up something.
> The other thing you'll need is a good hex editor with which you can pick
> apart the file and verify manually that what you expect to be present is
> actually there. I use and recommend "Hex Workshop" (www.bpsoft.com)
> however there are many good hex editors around so pick one you're
> comfortable with (One nice thing about HW that I'd not seen in other
> editors at the time (don't know if this is still the case) is its
> structure support, where you can define file structures and map them
> within a file, very handy for a number of formats.)
> Another thing to watch out for when writing your file parser is whether
> the file uses Little (Intel) or Big (Motorola) byte order. VB uses
> little-endian byte order for all its types, so if you're working with a
> format that stores its data in big-endian format then you would need to
> swap the byte order to properly interpret the values. Here's a couple of
> routines for converting integer types:
>
> '***
> Private Function FlipWord(ByVal inWord As Integer) As Integer ' Endian
> swap on Word
> FlipWord = ((inWord And &H7F) * &H100) Or (((inWord And &HFF00) \
> &H100) And &HFF)
> If (inWord And &H80) Then FlipWord = FlipWord Or &H8000
> End Function
>
> Private Function FlipDWord(ByVal inDWord As Long) As Long
> FlipDWord = _
> (((inDWord And &HFF000000) \ &H1000000) And &HFF&) Or _
> ((inDWord And &HFF0000) \ &H100&) Or _
> ((inDWord And &HFF00&) * &H100&) Or _
> ((inDWord And &H7F&) * &H1000000) ' Endian swap on DWord
> If (inDWord And &H80&) Then FlipDWord = FlipDWord Or &H80000000
> End Function
> '***
>
> And an old post demonstrating how to perform a endian flip on any type,
> specifically on floats and doubles:
> http://groups.google.co.uk/group/mi...df197051262c15b
>
> Also, many formats use unsigned values and again since all VB's integer
> types are signed these again require conversion to be interpreted properly
> in VB. Here's another old post with some code in the convert between
> signed and unsigned integer values:
> http://groups.google.co.uk/group/mi...3d78be2b514d0e1
>
> Finally, some formats these days support very large files and as such
> require very large numbers to handle offsets and such correctly. In these
> cases an 8-byte integer type (QWord) is used, but again since VB has no
> native support for these values, they must be converted to be used
> correctly. Here's another old post with some functions in for working
> with them should you need it:
> http://groups.google.co.uk/group/mi...47fea5d3bcb6ce0
>
> When writing your parser, always open the file in binary mode and unless
> you're working with textual data, never use strings for reading data in or
> writing data out to avoid ASCII <-> UNICODE and locale issues. Your other
> option is to use an API based file parser which is slightly more complex
> but gives you slightly more efficient data handling when working with
> large chunks of data, and is essential when working with large (>2 GB)
> files since VB's file handling routines will not cope with this.
>
> Armed with all that you should be picking apart files in no time, however
> if you have any more specific questions then post back here.
> Hope this helps,
>
> Mike
>
>
> - Microsoft Visual Basic MVP -
> E-Mail: EDais@mvps.org
> WWW: Http://EDais.mvps.org/
>

David Kerber

2006-07-03, 7:55 am

In article <uTTEYmpnGHA.3312@TK2MSFTNGP03.phx.gbl>,
bartsmissaert@blueyonder.co.uk says...
> Thanks for that.
> Is there a generic way to read file headers, without knowing anything about
> the structure of the file?

Nope. They are specific to the file type, and some types (.txt, for
example) don't have headers at all.

> Or is it not possible to determine what/where the header is without knowing
> the file structure?

That's correct.

> To be honest I don't really know exactly what a file header is precisely.

In this context, a header is information stored at a specific location
(often but not necessarily the beginning) inside the file, which tells
the program reading the file the information it needs to properly
process the data. For example, if you had a database file, this would
be things like field names and types, number of records in the table,
etc. For executable files, there is the "MZ" field, plus a bunch of
code. It is unrelated to file "properties" (such as creation date, last
modified date, size, etc), which are stored by the file system, and part
of the *contents" of the file.

.....

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

David Kerber

2006-07-03, 7:55 am

In article <MPG.1f12d9cc7db1adc49899b2@news.conversent.net>,
ns_dkerber@ns_WarrenRogersAssociates.com says...

....

> In this context, a header is information stored at a specific location
> (often but not necessarily the beginning) inside the file, which tells
> the program reading the file the information it needs to properly
> process the data. For example, if you had a database file, this would
> be things like field names and types, number of records in the table,
> etc. For executable files, there is the "MZ" field, plus a bunch of
> code. It is unrelated to file "properties" (such as creation date, last
> modified date, size, etc), which are stored by the file system, and part
> of the *contents" of the file.

That last sentence should read " and *not* part of the contents of the
file.

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

RB Smissaert

2006-07-03, 7:55 am

Thanks for clearing that up.

RBS

"David Kerber" <ns_dkerber@ns_WarrenRogersAssociates.com> wrote in message
news:MPG.1f12d9cc7db1adc49899b2@news.conversent.net...
> In article <uTTEYmpnGHA.3312@TK2MSFTNGP03.phx.gbl>,
> bartsmissaert@blueyonder.co.uk says...
>
> Nope. They are specific to the file type, and some types (.txt, for
> example) don't have headers at all.
>
>
> That's correct.
>
>
> In this context, a header is information stored at a specific location
> (often but not necessarily the beginning) inside the file, which tells
> the program reading the file the information it needs to properly
> process the data. For example, if you had a database file, this would
> be things like field names and types, number of records in the table,
> etc. For executable files, there is the "MZ" field, plus a bunch of
> code. It is unrelated to file "properties" (such as creation date, last
> modified date, size, etc), which are stored by the file system, and part
> of the *contents" of the file.
>
> ....
>
> --
> Remove the ns_ from if replying by e-mail (but keep posts in the
> newsgroups if possible).

Larry Serflaten

2006-07-03, 7:55 am

"RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote

> To be honest I don't really know exactly what a file header is precisely.

Put in simple terms, a header is that part of the file that helps to
correctly interpret the data contained in the file.

For one example, consider your post that I am responding to.
It is a newsgroup posting, and it has different parts. The part
you typically see is the message itself, but along with that message
there is other information. In your specific case the message header
was:

From: "RB Smissaert" <bartsmissaert@blueyonder.co.uk>
References: <uHcVSafnGHA.3340@TK2MSFTNGP02.phx.gbl> <udNF4wfnGHA.3440@TK2MSFTNGP04.phx.gbl>
<uWlTE$fnGHA.780@TK2MSFTNGP04.phx.gbl> <#D0Y3vinGHA.1604@TK2MSFTNGP03.phx.gbl> <u$ADe3inGHA.2432@TK2MSFTNGP03.phx.gbl>
<O#pIdBpnGHA.4864@TK2MSFTNGP04.phx.gbl>
Subject: Re: Read file properties
Date: Mon, 3 Jul 2006 13:09:27 +0100
Lines: 93
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-ID: <uTTEYmpnGHA.3312@TK2MSFTNGP03.phx.gbl>
Newsgroups: microsoft.public.vb.general.discussion
NNTP-Posting-Host: 82-37-28-137.cable.ubr04.wolv.blueyonder.co.uk 82.37.28.137
Path: TK2MSFTNGP01.phx.gbl!TK2MSFTNGP03.phx.gbl
Xref: TK2MSFTNGP01.phx.gbl microsoft.public.vb.general.discussion:596170

If you save that post to a file, all of that extra information gets saved
with the message. The term header is a generic term to refer to all the
extra information a file might have. In this case, you'll find that the
saved file is simply an ASCII file with all that extra information. You
could load that file into Notepad and see it all. I mention that to
differentiate the header a file might have from the format a file has.
The saved file is in the ASCII format, so any text reader capable
of showing text should be able to read it. The format of that file
might simply be described as:

<HeaderText>
<MessageText>

Which means the message text follows after the text in the header.

Typically, ASCII files will have the extension of .txt, indicating the
format of the file is ASCII text. Likewise, .jpg, .bmp, .wav, .doc,
and other common extensions all indicate what format to expect
from the file contents.

If I give you some file with the extension *.XYZ what do you
suppose you could do with the file?

Thus, you need to know the format a file has. Whoever saved the
file should have used a common format if they want others to be
able to read it. That means .XYZ has to have been defined publically,
and from the .XYZ specification you can determine where to look for
data, and where to look for any extra information. et. al....

Again, www.wotsit.org is a great site to go to to find out the format
of many different file types....

LFS

RB Smissaert

2006-07-03, 7:55 am

Thanks for clearing that up.
I somehow thought that the header of the file would always be at at the
start
of the file and could always be separated from the contents part of the file
easily.
I understand now that that is not the case.

RBS

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:Ok9v6XqnGHA.3700@TK2MSFTNGP03.phx.gbl...
>
> "RB Smissaert" <bartsmissaert@blueyonder.co.uk> wrote
>
>
> Put in simple terms, a header is that part of the file that helps to
> correctly interpret the data contained in the file.
>
> For one example, consider your post that I am responding to.
> It is a newsgroup posting, and it has different parts. The part
> you typically see is the message itself, but along with that message
> there is other information. In your specific case the message header
> was:
>
> From: "RB Smissaert" <bartsmissaert@blueyonder.co.uk>
> References: <uHcVSafnGHA.3340@TK2MSFTNGP02.phx.gbl>
> <udNF4wfnGHA.3440@TK2MSFTNGP04.phx.gbl>
> <uWlTE$fnGHA.780@TK2MSFTNGP04.phx.gbl>
> <#D0Y3vinGHA.1604@TK2MSFTNGP03.phx.gbl>
> <u$ADe3inGHA.2432@TK2MSFTNGP03.phx.gbl>
> <O#pIdBpnGHA.4864@TK2MSFTNGP04.phx.gbl>
> Subject: Re: Read file properties
> Date: Mon, 3 Jul 2006 13:09:27 +0100
> Lines: 93
> MIME-Version: 1.0
> Content-Type: text/plain;
> format=flowed;
> charset="iso-8859-1";
> reply-type=response
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
> Message-ID: <uTTEYmpnGHA.3312@TK2MSFTNGP03.phx.gbl>
> Newsgroups: microsoft.public.vb.general.discussion
> NNTP-Posting-Host: 82-37-28-137.cable.ubr04.wolv.blueyonder.co.uk
> 82.37.28.137
> Path: TK2MSFTNGP01.phx.gbl!TK2MSFTNGP03.phx.gbl
> Xref: TK2MSFTNGP01.phx.gbl microsoft.public.vb.general.discussion:596170
>
>
> If you save that post to a file, all of that extra information gets saved
> with the message. The term header is a generic term to refer to all the
> extra information a file might have. In this case, you'll find that the
> saved file is simply an ASCII file with all that extra information. You
> could load that file into Notepad and see it all. I mention that to
> differentiate the header a file might have from the format a file has.
> The saved file is in the ASCII format, so any text reader capable
> of showing text should be able to read it. The format of that file
> might simply be described as:
>
> <HeaderText>
> <MessageText>
>
> Which means the message text follows after the text in the header.
>
> Typically, ASCII files will have the extension of .txt, indicating the
> format of the file is ASCII text. Likewise, .jpg, .bmp, .wav, .doc,
> and other common extensions all indicate what format to expect
> from the file contents.
>
> If I give you some file with the extension *.XYZ what do you
> suppose you could do with the file?
>
> Thus, you need to know the format a file has. Whoever saved the
> file should have used a common format if they want others to be
> able to read it. That means .XYZ has to have been defined publically,
> and from the .XYZ specification you can determine where to look for
> data, and where to look for any extra information. et. al....
>
> Again, www.wotsit.org is a great site to go to to find out the format
> of many different file types....
>
> LFS
>
>
>
>
>
>
>
>
>

David Kerber

2006-07-03, 6:56 pm

In article <#1jk9bqnGHA.3772@TK2MSFTNGP04.phx.gbl>,
bartsmissaert@blueyonder.co.uk says...
> Thanks for clearing that up.
> I somehow thought that the header of the file would always be at at the
> start
> of the file and could always be separated from the contents part of the file
> easily.

Hah! We wish!!!

.....

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

Mike D Sutton

2006-07-03, 6:56 pm

>> I somehow thought that the header of the file would always be at at the start
>
> Hah! We wish!!!

Now then, where'd the fun be in that?? ;)

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

Sponsored Links