How to determine if a file is busy?

B

Busyman

Hi,

I have written a stay-open-AppleScript for Mac OS X, gathering certain
informations from different apps, which can only be gathered via
AppleScript. This script writes its informations into a simple text
file, every 15 seconds. And a python script is supposed to read this
text file on a regular basis in order to feed the aquired datat into a
database working only on Windows. Now the problem: How can I prevent
that the python script reads the content of the text file, while my
AppleScripts writes new information to it? Is there any 'busy'-status
for files?

Thanks in advance from cold and cloudy Germany!

Martin
 
A

Alex Martelli

Benjamin Niemann said:
How about writing the data to a file 'mydata.new' and when you are finished,
delete 'mydata' and rename 'mydata.new' to 'mydata'.
This way the python script will always get 'complete' files (and sometimes no
file at all, when it come in between rm and mv ...)

I believe that 'mv' on Mac OS X, within a normal filesystem, is an
atomic operation anyway -- so, so need to rm first then mv. On the
other hand, this would give no intrinsic guarantee that the datafile
previously produced HAS been consumed/recorded before it's removed.


Alex
 
A

Andreas Kostyrka

I believe that 'mv' on Mac OS X, within a normal filesystem, is an
atomic operation anyway -- so, so need to rm first then mv. On the
other hand, this would give no intrinsic guarantee that the datafile
previously produced HAS been consumed/recorded before it's removed.
Then the consumer of that file should remove it afterwards.

Andreas
 
A

Alex Martelli

Andreas Kostyrka said:
Then the consumer of that file should remove it afterwards.

Possibly, but that, per se, doesn't mean a file can't get deleted
without ever having been used. If the producer must wait for the
deletion (not necessarily easy in AppleScript, I believe) then the
producer could be stalled by the implied 1-length 'queue'...

I'm not sure about the best solution because I'm unsure about the exact
abilities of AppleScript, where the Python script is running (on Windows
with a [EEK] SMB share to the Mac, or on the Mac itself), etc...


Alex
 
B

Benjamin Niemann

Alex said:
Then the consumer of that file should remove it afterwards.


Possibly, but that, per se, doesn't mean a file can't get deleted
without ever having been used. If the producer must wait for the
deletion (not necessarily easy in AppleScript, I believe) then the
producer could be stalled by the implied 1-length 'queue'...

I'm not sure about the best solution because I'm unsure about the exact
abilities of AppleScript, where the Python script is running (on Windows
with a [EEK] SMB share to the Mac, or on the Mac itself), etc...

The AppleScript could rename the .new file to .[timestamp], producing a new file
for each iteration. The Python script would consume & delete all .[timestamp]
files in lexical order, but must ignore the .new file if it happens to be there.
 
M

Martin Michel

Alex Martelli said:
I believe that 'mv' on Mac OS X, within a normal filesystem, is an
atomic operation anyway -- so, so need to rm first then mv. On the
other hand, this would give no intrinsic guarantee that the datafile
previously produced HAS been consumed/recorded before it's removed.


Alex

First of all: Thanks so much for your help! I am really astonished about
everybody doing his best to find a solution for my problem.

It might sound funny, but it is not important, that a specific data file has
already been consumed. For me, it is only important, that my Python script
does not open & read a file, which is currently in use by my AppleScript.
It's more like a webcam thing: If a picture taken by the cam, is not put
into the album/webserver, that is no problem, because there will be other
pictures taken by the cam in the future.

The platform independence of Python is great for me as I can fetch the
informations from a Windows XP PC and a Mac to feed the database running in
our electroplating company, but I am also happy to program all the rest of
the application in Python, because as much as I do like AppleScript (Studio)
for its power on the Mac, I hate writing its longish code leading to big
scripts doing little things...Python is just so snappy ;-) (for someone who
has coded a long time in AppleScript)

I am now trying to implement something like a temp file, which I will
finally (after writing all the informations into it) copy into an export
location, where the Python script can fetch it any time. My only concern is,
if copying is also a problem (Python script reads the text file, while the
copy process is not yet finalized...)....

Thanks so much once again, you are a great community, Python is a great
lannguage!

Martin
 
A

Alex Martelli

Benjamin Niemann said:
The AppleScript could rename the .new file to .[timestamp], producing a
new file for each iteration. The Python script would consume & delete all
.[timestamp] files in lexical order, but must ignore the .new file if it
happens to be there.

Sounds good to me, placing minimal demands on the AppleScript's
abilities (surely getting a timestamp and doing a rename is well within
its powers!) _and_ on the filesystem used for communication (surely this
small subset of "atomicity of renames" -- which appears to be the only
issue here -- can be guaranteed even by SMB).


Alex
 
A

Alex Martelli

Martin Michel said:
I am now trying to implement something like a temp file, which I will
finally (after writing all the informations into it) copy into an export
location, where the Python script can fetch it any time. My only concern is,
if copying is also a problem (Python script reads the text file, while the
copy process is not yet finalized...)....

Renaming, as suggested on the other subthread, sounds preferable to
copying, more likely to be an atomic operation on any kind of shared
filesystem. Your applescript should write 'foobar.new' (either directly
in the export location, or copying it there each time it's ready) then
rename it to something like 'foobar.ready_20041008_171921' or other
unique name that's easily identifiable (this example uses a timestamp in
an order Y-M-D-h-m-s that will automatically "sort right").

Python can periodically look for 'foobar.ready_*' files in the export
location, and consume and delete them -- if it finds more than one it's
up to you whether it should consume all or just the newest one, but all
should be deleted anyway, whether they're consumed or otherwise ignored.

This protocol appears to me to be quite safe, with minimal demands on
the filesystem you're sharing.


Alex
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top