All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Erik Terpstra <erik@solidcode.net>
Cc: reiserfs-list@namesys.com
Subject: Re: Can ReiserFS solve this?
Date: Mon, 28 Apr 2003 18:53:34 +0400	[thread overview]
Message-ID: <3EAD406E.5040108@namesys.com> (raw)
In-Reply-To: <3EAD34D5.8030108@solidcode.net>

Erik Terpstra wrote:

> Hi,
>
> I am looking for a solution for the following problem:
>
> On a legacy system for newspaper workflow, files are delivered to a 
> certain directory (for example ~/input).
> These files (in TIFF format) can be quite large (10 to 400 MB), they 
> could be copied over the local filesystem, a Samba share or via FTP.
> When large files are copied over the network these files show up in 
> ~/input while they are being copied (you can see the filesize grow).
>
> However TIFF files are only useful for further processing when they 
> are complete.
>
> Initially we solved this problem by monitoring the input directory and 
> make our applications look at the files until they stop growing, but 
> this isn't a very elegant and reliable method.
>
> After a while we discovered the UNIX 'fuser' command so that we could 
> see if the incoming file is still being transferred or not.
> This works fine but it's still not very elegant, and it requires root 
> privileges for the applications involved in the workflow.
>
> Naturally, the best solution would be for the sender to notify the 
> completion of the transfer. But this is not an option because several 
> organizations are involved that do not wish to adapt their software.
>
> Right now I am wondering if this is something that could be solved on 
> the filesystem level, i.e. is it possible to 'only see files that are 
> not in the process of being transferred'.
>
> Is this possible with Reiser3? Reiser4? Should it be solved on the 
> filesystem level?
>
> Any thoughts on this matter are appreciated.
>
> Kind regards,
>
>   Erik Terpstra.
>
>
>
Is there a test for completeness of the tiff?  It could be done as a 
reiser4 plugin.

-- 
Hans



  parent reply	other threads:[~2003-04-28 14:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-28 14:04 Can ReiserFS solve this? Erik Terpstra
2003-04-28 14:17 ` Valdis.Kletnieks
2003-04-28 14:26   ` Erik Terpstra
2003-04-28 16:11     ` Christian Mayrhuber
     [not found]   ` <1742847756.20030428162843@tnonline.net>
2003-04-28 14:39     ` Anders Widman
2003-04-28 14:32 ` Oleg Drokin
2003-04-28 14:42   ` Valdis.Kletnieks
2003-04-28 14:52     ` Chris Dukes
2003-04-28 14:53     ` Oleg Drokin
2003-04-28 14:53     ` Anders Widman
2003-04-28 15:21       ` Hans Reiser
2003-04-28 15:45   ` Yury Umanets
2003-04-28 19:48     ` Soeren Sonnenburg
2003-04-28 14:53 ` Hans Reiser [this message]
2003-04-28 15:24   ` Erik Terpstra
2003-04-28 15:52     ` Erik Terpstra
2003-04-28 16:36 ` Kristian Koehntopp
2003-04-28 17:37 ` Anders Widman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EAD406E.5040108@namesys.com \
    --to=reiser@namesys.com \
    --cc=erik@solidcode.net \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.