Re: Open files
Re: Open files
- Subject: Re: Open files
- From: John W Baxter <email@hidden>
- Date: Sat, 16 Mar 2002 18:01:02 -0800
At 17:06 +0000 3/16/2002, Nigel Garvey wrote:
>
Paul Berkowitz wrote on Fri, 15 Mar 2002 21:02:11 -0800:
>
>
>On 3/15/02 8:33 PM, "Shane Stanley" <email@hidden> wrote:
>
>
>
>> On 16/3/02 2:58 PM +1000, Paul Berkowitz, email@hidden, wrote:
>
>>
>
>>> In the event that a script is aborted when a file which has been opened
>
>for
>
>>> access (esp. with write permission) is still open, is there any way to
>
>ask
>
>>> the system to return file reference numbers of open files, so that one
>
>can
>
>>> close access of them instead of having to reboot?
>
>>
>
>> Why not just close it by path?
>
>
>
>I thought I recalled that it wasn't supposed to work reliably if you had
>
>opened it with write permission, or that you couldn't write to it again. I
>
>thought that the instance which was opened with write permission needs to be
>
>closed by file reference. Nigel went into this exhaustively at one time, I
>
>recall. Perhaps that was with an earlier, faulty version of Standard
>
>Additions. I seem to recall changes being made in both v1.5.5 and 1.6, maybe
>
>1.7.
>
>
My exhaustive tests were with AS 1.3.7 - and my conclusions were later
>
confirmed by simply reading the AS Scripting Additions Guide. 8-\
>
>
When an open file's referred to by path, the system uses the first
>
existing 'open for access' reference for that file that comes to hand. If
>
there's only one such reference, closing the file using the path closes
>
that reference and all's well.
>
>
That's the likely situation, but it's possible for a file to be open
>
several times at once, each opening having its own reference and
>
associated file pointer. Only one of these references can have write
>
permission. If that's the reference you've lost, you'll have to keep
>
closing the file by path until the appropriate reference surfaces and its
>
closure enables you to reopen the file with write permission. This may
>
have implications for other processes which haven't lost their references
>
and are trying to read the file.
Experiments in Mac OS X 10.1.3 (AppleScript is 1.8...the December Developer
Tools are present along with the update to the December Developer Tools,
but AS betas have not been installed).
YMMV. Use at your own risk. Don't run with scissors.
Suppose we run the following script (which, clearly, loops...with a second
processor that's not noticeable here).
set x to open for access "tmp:xxxxxxxxxx" with write permission
display dialog x
set y to open for access "tmp:yyyyyyyyyy" with write permission
display dialog y
repeat
end repeat
On my machine when I ran this, x was 182 and y was 185.
Now, in a Terminal window, run lsof, which lists open files (and which has
thousands of options...would you believe more than a dozen). After you
recover from the mass of data, run
bash2.05 john@fox /tmp % lsof |grep '\(xxxx\)\|\(yyyy\)'
LaunchCFM 2054 john 12u VREG 14,8 0 509144
/private/tmp/xxxxxxxxxx
LaunchCFM 2054 john 13u VREG 14,8 0 509145
/private/tmp/yyyyyyyyyy
where the grep gets rid of everything not of interest here...the regular
expression selects lines which contain xxxx OR yyyy. [Get out a box of
toothpicks...they're helpful in writing regular expressions.]
Many screens down the man page, we learn that the column containing the 12u
and 13u contains the FD (file descriptor) number. The u means open for
both reading and writing (r is open for reading; w is open for just
writing, and space and - mean "huh?...don't ask me").
So, FD number 12 was--this time--associated with the AppleScript file
reference 182, and 13 is associated with file reference 185.
So we may have this pair of equations to solve:
12a + b = 182
13a + b = 185
Further, we have a strong hint that a might be 3 (which isn't needed to
solve the equations, but does make the task trivial).
So...b is 146 and a is 3.
So if you're cleaning up manually, it should be possible to run the lsof
followed by grep filename, and pick out the FD which belongs to the
writable file, and compute 3*FD + 146, and feed that into close access in a
separate script.
Indeed, I ran
close access 12 * 3 + 146
in another script (the first one having been stopped with the Stop button),
and then ran the lsof ... grep ... again:
bash2.05 john@fox /tmp % lsof |grep '\(xxxx\)\|\(yyyy\)'
LaunchCFM 2054 john 13u VREG 14,8 0 509145
/private/tmp/yyyyyyyyyy
And the lsof output no longer included the file xxxxxxxxxx
If you want to automate this, it ought to be possible to send the output of
lsof to an appropriate sed or awk script, and get back the FD number (as a
string) to be used in close access 3 * FD + 146. Writing that is left as
an exercise for the reader. Something like
set FD to (do shell script "lsof | sed blah blah blah") as number
Will this work tomorrow? I don't know.
Will it work if several users are logged in at once (most of them,
presumably, via ssh from another machine or machines and running their
scripts from the command line)? I don't know.
YMMV. Use at your own risk. Don't run with scissors.
--John
--
John Baxter email@hidden Port Ludlow, WA, USA
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.