Confirming a Save command

[John Kiltinen]

Thanks to those of you who responded to my inquiry of the subject line.

Glen Yates <JAMES.G.YATES at saic.com> wrote:
>Um, wouldn't it be easier to just check the result of your save command.
>
>For Example:
>
>	save stack "yourstack"
>	if the result is not empty then
>		#stack wasn't saved
>		#put error handler here
>	else
>		#everything was hunky-dory
>	end if
>
>-Glen Yates

Aha!  There is a nonempty "result" variable returned after a save if it did
not happen normally.  This is the sort of thing I was looking for, but
could not find.  Wouldn't it be great if the documentation told basic
things like this?

Glen, how do YOU find out these important little details?

I've tested this procedure out, and have found that on the Macintosh
platform, if the stack being saved is locked, the save command produces a
copy of the stack with the same name and followed by a tilde.  One also
gets a message in the result variable which says "Can't open stack file".
If you save a second time, the message in result is "Can't open stack
backup file".

While this approach is promising, I am not quite sure if I want this sort
of behavior.

Jacqueline Landman Gay <jacque at hyperactivesw.com> wrote:
>I can't think of a way to get the info directly, but the function "the
>detailed files" returns a list of file attributes for all files in the
>current directory. One of the attributes is the last modification date
>in seconds. So you could at least skip all the closing, deleting, and
>re-opening part of the script by just checking the last modification
>date. The script needs to parse out the name of the file you are
>interested in, since "the detailed files" returns a whole list.

This approach looks good too.  Unfortunately I have been committed to
version 2.3.2 of MetaCard for over a year, and it appears that the
"detailed" option on the files function came in with a later release.  I
have been avoiding moving the stack up to a later version in case

Shari <gypsyware at earthlink.net> wrote:

>What about getting the effective filepath of the stack?
>
>The first entity is the volume, and if the volume is the CD itself
>then the save didn't happen.
>
>Or consider putting only the stuffed version on the CD, forcing them
>to install it on the hard drive so that it will function properly.
>
>Shari C

These ideas are good ones to rule out the problem of people running the
program off of the CD.  I might go that route, especially on the Windows
platform.  However that doesn't deal with the possibility that somebody
puts a stack on their hard drive into read only or locked mode.

Sjoerd <sjoerdoptland at mac.com> wrote:

>What about just writing a file:
>
>  put "aaa" into url ("file:" & thePath & "/test.dat")
>  if url ("file:" & thePath & "/test.dat") is not "aaa" then
>    -- warning stuff here
>  end if

Writing a test file to the same drive that the stack is on would be a
strategy to deal with an attempt to save to a CD ROM, but I can't see that
it would address the problem of a locked stack on the hard drive.

I am still mulling what will be the best strategy, but these ideas have
certainly given me more options to consider.  I am sure that the solution I
adopt will come from among them.

John Kiltinen


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 John Kiltinen (kiltinen at nmu.edu)        Home              Office
 Professor, Dept. of Math. & CS   Tel.(906) 228-8035 or (906) 227-1600
 Northern Michigan University     Fax (906) 228-4667 or (906) 2272010
 Marquette, MI 49855 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++