O$ - FileOps strangeness...

[Reg Paling]

Hi David,

I once spent some time fiddling around in exactly the same situation as 
you, and realised it's better to just use $readfile and $writefile.

While it looks like a good idea to use $readentirefile, once you think 
it through, it's not unless you know your application will only ever be 
Mac-only.

Particularly in the case of a library, you already know what the 
filetype and creator are so you don't need to read them off the disk.

So I suggest just changing all your $readentirefile to $readfile and all 
$writeentirefile to $writefile, (you'll need to re-load any library file 
images you already have in the database), and from there it will work 
fine on both platforms.

Do lvFileOpsObj.$createfile(lvPath,'OO$A','OO$$')
Do lvFileOpsObj.$writefile(lvTempBin) Returns lvResult
If lvResult=1
Else
   OK message Couldn't download library (Sound bell) {Error from 
$writefile - error code: [lvResult]}
End If
Do lvFileOpsObj.$closefile()

Cheers,
Reg


David Walton wrote:
> Kelly,
>
> Seems I am now encountering an issue with the 12 byte header - which 
> isn't being read - or written. Don't know how to get windows to read 
> it...
>
> Any ideas?
>
> It gives the message that Omnis can't read the library file (the one 
> I'm reading and writing).
>
>
> In brief, here's what I'm doing...
>
> There's a version update button that , when clicked, prompts for a 
> library file. The file is read and placed into the database. Then, 
> when a client logs in, it fetches the most current library file and 
> replaces their local copy. Then it relaunches the library again.
>
> I can look at the binary that is written to the database from windows 
> and it doesn't have the 12 byte header. I assume that is causing 
> windows to not understand the file type???
>
> Thanks.
>
> On Apr 17, 2009, at 7:44 PM, Kelly Burgess wrote:
>
>> Hi David,
>>
>>> Do FileOps.$readentirefile(ipath,lbinary) returns lstatus
>>>
>>> This works fine on OSX but lstatus returns -47 (open file error) on XP.
>>
>> I've never used this function on Windows.  Its advantage is that on 
>> Mac it collects both data and resource forks of a file - if they both 
>> exist. Even for files that don't contain a resource fork, the binary 
>> returned will still have a 12-byte header containing Mac file type 
>> and creator, and an offset to a potential resource fork, a.k.a. the 
>> size of the data fork following the header.
>>
>> So on Windows I'd be inclined to use a FileOps object with 
>> $open/$read/$close instead.
>>
>> Kelly
>>
>