Re: Moving large PDF files with Applescript
Re: Moving large PDF files with Applescript
- Subject: Re: Moving large PDF files with Applescript
- From: "John C. Welch" <email@hidden>
- Date: Wed, 01 Apr 2009 14:44:43 -0400
- Thread-topic: Moving large PDF files with Applescript
Title: Re: Moving large PDF files with Applescript
On 4/1/09 1:57 PM, "Mark J. Reed" <email@hidden> wrote:
That's assuming the only way to use the timing loop is to check for
increases.
That's what the code posted so far has done.
A certain amount of “do your own thinking” is assumed on a programming list.
The obvious solution here is to compare the current size of the
written file to the known size of the complete file.
Great! Where do we find out this "known" size of the complete file? How do we convey that information to the receiving process? Writing another file ahead of time with the size of the data file in it doesn't seem to be any improvement over the '.end' file technique.
You know the size of the file when you start the transmission. That’s trivial to obtain. Please don’t make me explain something that basic. By the same token, you can check the size of the file on the receiving end with the same method, since the location and name of the file are known. At that point, it’s “If sourceFile size < destFile Size, do nothing”
Really, it’s not that hard to figure out.
> If this is a common problem, the transfer code could check for files
> that are in the folder and older than a certain time (say 1 day, 1
> week) and then offer to delete them or move them. Or you could just
> manually clean up once in a while.
That's complicating things even more.
You're going to get failures and have to deal with them somehow no matter what. The .end file technique leaves the system in a known state in the face of failures, rather than with something trying to process an incomplete file.
No, it doesn’t. It assumes that the file transfer went okay in absence of an error. I have seen files appear to have transferred correctly, because the transfer ended without an error, but a comparison of sizes shows different.
Dealing with failures does complicate things, but it doesn't OVERcomplicate them. Everything should be "as simple as possible - and no simpler".
What’s simpler? Comparing file sizes, or dealing with additional file system reads/writes and no actual verification whatsoever that just because the transfer ended may not mean it did what you thought. It’s not CRC, but it’s better than assumption.
Code that requires manual intervention or additional verification and
cleanup processes isn't exactly exciting either.
Any automated process of any useful level of complexity is going to require some level of checking up, manual or otherwise. What's important here is that the .end file technique gives any failures a *smaller* impact than the timing loop, and so can go longer without anyone having to worry about that stuff, on average.
And as I have shown, there are ways to rewrite the delay loop to minimize that completely, including being able to take out the delay completely, and by using file size, you gain a better method of built-in checking than the assumption that lack of error always means correct transfer.
--
"Klingon multitasking systems do not support "time-sharing". When a Klingon program wants to run, it challenges the scheduler in hand-to-hand combat and owns the machine."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden