roy@cs.umn.edu> (05/01/91)
Given the conflicting opinions about Prodigy and the STAGE.DAT file, I believe there is a fairly easy way to determine the truth. I have a TSR utility that will record every DOS call made by a program. If I had a Prodigy kit, I would run it under this TSR and examine the resulting DOS call log for unusual actions. If, indeed, the STAGE.DAT file is copying erased information, nothing untoward may be intended. However, if the logfile shows Prodigy's front-end snooping about on my hard drive partitions, I think that will speak for itself. Anybody got a spare (virgin) Prodigy kit to donate to the investigation? Roy M. Silvernail roy%cybrspc@cs.umn.edu cybrspc!roy@cs.umn.edu roy@cybrspc.uucp (maybe!) [Moderator's Note: You are welcome to try this experiment, and by all means report back on the results, but the consensus here over the past two days in messages is that the whole thing is really a non-issue ... just a case of Prodigy grabbing up 'empty' space to store stuff. PAT]
"Louis J. Judice 02-May-1991 1033" <judice@sulaco.enet.dec.com> (05/02/91)
> I know its off the topic, but ... if you are on a multi-user system > and this technique works for you ... switch. That is terrible > security and the vendor deserves not to be in business (don't name > names, I know several which work this way). Since most of our > multi-user readers are on UNIX, this trick will not work on UNIX > systems. > Two reasons: First, UNIX does not allocate the intervening > space in the file. It just allocates the blocks you write to. The OS > returns 0's for all other blocks read that are not yet allocated. > Second, UNIX does not write partial sectors, nor depend on the > contents of the file to mark end of file. Not to stray even further off the topic, but I would caution readers that in a production environment, this "feature" would probably end up requiring a lot more I/O, especially on a fragmented disk. Your best bet is to use file highwater marking techniques on timesharing disks and permit preallocated files on disks holding large production databases. My guess is that most big UNIX database systems work the latter way, using raw I/O. And of course other operating systems, like VMS, also let you "go both ways." :) ljj