C#

<br />
bool uploadCompleted = false;<br />
do<br />
{<br />
     try<br />
     {<br />
          File.Open("yourFileName", FileMode.Open, FileAccess.Read).Close();<br />
          uploadCompleted = true;<br />
     }<br />
     catch<br />
     {<br />
     }<br />
}<br />
while (uploadCompleted != true)<br />

Luc Pattyn wrote:

If you cant follow the above scheme (e.g. because the file format has been fixed
and does not include a type byte), then you need to determine the type of the next record
by reading and analyzing some bytes, then rewind a bit (using
Seek method or Position property) and Load a record; repeat until done.

- use one FileStream for your file
- use BinaryReader.ReadBytes() to read a number of bytes at the current position (it will
  advance the current position); problem here is you must specify the byte count
- create a number of classes or structs, one for each possible record type.
- if class/struct RecordType1 is one of the possible record types, you should give it
  two static methods:
bool Accept(FileStream) would read some bytes and decide whether or not the data fits the
record type for that class/struct; it should restore the filestream position as if
nothing happened (use FileStream.Position property to remember where you are in the file,
and to return to that position); it should not throw exceptions to the caller.
RecordType1 Load(FileStream) would read all the bytes needed to load a record of that type,
knowing it is of that type (since it will have been Accepted beforehand). Load does
advance the filestream, so it consumes the record and returns the result. It should throw
exceptions when something fails.
- details on Accept: you can try and recognize the first few bytes; JPEG always start
  with FF D8 and often with FF D8 FF E0; but nothing prevents other (non JPEG) records
  to also start with FF D8 !! So your collection of Accept() methods should be sufficiently
  accurate to discern the record types at hand.
- details on Load: you should know the byte count in order to read the right number
  of bytes; scanning for an end marker is difficult: even if JPEG always ends on FF D9,
  that does not mean the first FF D9 is the end of a JPEG (it could be a bit pattern
  in the middle of the pixel info).
- it is rather hard to decode JPEG, so I suggest to let GDI+ try and decode a JPEG image.
  One way would be to create a memory stream from your byte array, then call
  Image.FromStream(MemoryStream), but I suspect you could directly call
  Image.FromStream(FileStream) avoiding the byte count problem completely.
- you can create a new BinaryReader in every Accept and every Load method in each
  RecordType class/struct, or reuse a single one all over the place (dont try something
  intermediate).
- also provide a class/struct to handle the end-of-file record; it needs an Accept
  but does not need a Load() method.
- and now the finale: put all your Accept and Load methods in one loop to decode the
  entire file, as in:

try {
    FileStream fs=...
    for ( ; ; ) {   // each iteration reads one record, until end-of-file record is seen
        bool accepted=false;
        if (RecordType1.Accept(fs)) {
            accepted=true;
            RecordType1 rec1=RecordType1.Load(fs);
            ...do whatever needs to be done with rec1
            continue;
        }
       if (RecordType2.Accept(fs)) {
            accepted=true;
            RecordType2 rec2=RecordType2.Load(fs);
            ...do whatever needs to be done with rec2
            continue;
        }
        ...etc
        if (RecordTypeN.Accept(fs)) {
            ...this one recognizes end of file
            ...close the shared BinaryReader if there is one, close the FileStream
            break;
        }
       if (!accepted) throw new ApplicationException("Cant recognize record...");
    }
} catch(Exception exc) {
    ... handle the exception
}

- the order of the RecordType# blocks may be relevant, since the first one that
  returns a true on Accept will (have to) consume the data, so put the most strict
  acceptors first.

htres wrote:

each record has a fixed 223 byte header

htres wrote:

wrote it to disk, named it .jpg, and tada, I had the jpeg image

Luc Pattyn wrote:

I would not fully trust the string.IndexOf part, since string operations
perform unpredictably on non-string data (such as JPEG images, which can
contain any bit pattern, that could be misinterpreted as Unicode characters).

Luc Pattyn wrote:

htres wrote:
each record has a fixed 223 byte header

That's new info, makes things easier I guess.

Luc Pattyn wrote:

htres wrote:
wrote it to disk, named it .jpg, and tada, I had the jpeg image

As I mentioned earlier if you want the image I guess you can do it without
such file using Image.FromStream(); if you need the file, then it is the
way to go.