Interesting. Perhaps you can go about it this way:
1) Have the users upload to a certain directory, then (once the file is on
the local server) move the file to this so-called watch directory. A move
from the same hard disk will be much quicker, avoiding the distiller process
mucking things up. - Although most ftp servers (out-of-the-box) allow
commands such as mv to be envoked - this is a bit cumbersome for the
uploader.
A more streamlined way would be to employ a web server that serves up a cgi
page... perl can do the following:
1) provide a web interface to submit files via http, then execute this
distiller process and output the file all in one perl script. That would be
pretty slick. There are plenty of perl examples out there for doing this
sort of thing. This way, you can get rid of this cron job, or whatever it is
you have running in opt for an on-demand sort of execution, all via a web
browser, as far as the uploader is concerned. This would be a bit more work,
but I can't think of a cooler way to do it...
"Lince M Lawrence" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) m...
> I am working in a Linux-Macintosh Network. And I transfer numerous
> files to Macintosh from Linux. I am having a problem while doing so.
> We have created a watch-folder in Macintosh for PDF conversion
> (distilling ps to pdf), which checks the specified folder for the
> presence of files every 180 seconds. If I am transferring a relatively
> big file at the 175th second, (and it would take another 60 seconds to
> get transferred completely) the active watch folder will pick the
> incomplete file for distilling, ending up with a corrupt PDF.
>
> Somebody please help me by suggesting a method (command) to lock/block
> a file from further operation till it is transferred completely. The
> user may be transferring a file either by ncftp or ssh from Linux to
> Macintosh, and he can unlock/de-block the file when the transfer is
> complete; which eventually enables the watch-folder to identify the
> file.
>
> Hope my requirement is clear.
>
> Thanks,
> Lince M Lawrence
|