views:

82

answers:

1

The Scripting.FileSystemObject TextStream object supports Windows style Unicode and 'plain text' modified by the system codepage, but does not appear to support UTF8 -- However, it can actually stream files that are locked for updates, such as an IIS logfile.

ADODB.Stream supports UTF-8 (or raw binary), but will not "LoadFromFile" a file that has been locked for updating, despite the file being openable in, say, notepad. ( Results in the error: ADODB.Stream File could not be opened. with an error code of 0x800a0bba ) -- This despite trying to open the stream in "Read" mode or "Shared" mode. Seems as though the server-side COM object demands more locking than I actually request it to.

Are there any other alternatives? I am invoking these remotely via DCOM, however even testing on the host system itself results in the same behaviour.

Ideally there would be a component that would act as a stream (i.e. support seek mechanisms), can either stream the raw bytes (binary) or can handle plain text, Unicode, and UTF-8, and can read files that are open for writing. Anyone know of such a beast?

A: 

I'm not sure this is what you're looking for, but you can built your own server-side streamer, take a look at IPipeByte. It is an interface that exists since win2k, and will allow you to easily stream bytes between the client and the server. Since you'll be doing the actual reading from the file, the permissions issues are going to be only the ones that the OS imposes on you. And, of course, the text format will not be an issue at all.

There's a good article about using pipes, which can be found here. The example code is missing, but it could probably be found in offline MSDN.

eran
I'll have a look at this, thanks. Ideally I'd use a pre-existing object/component, but if I have to roll my own, this could be quite helpful.
Dan Fleet
It's been a while since I used pipes, but IIRC the example code is quite ready to be used as is, and with modifying it to suite your needs should be quite easy. The pipe plumbing is done, which leaves only the file handling stuff.
eran
I didn't end up using pipes, but did try self-wrapping a stream object and exposing it via DCom to do what I needed. I had no luck locating an 'official' remotely accessible stream implementation that worked equally as well with write-locked files AND unicode or UTF-8.
Dan Fleet