All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erik Terpstra <erik@solidcode.net>
To: reiserfs-list@namesys.com
Subject: Can ReiserFS solve this?
Date: Mon, 28 Apr 2003 16:04:05 +0200	[thread overview]
Message-ID: <3EAD34D5.8030108@solidcode.net> (raw)

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.


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

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-28 14:04 Erik Terpstra [this message]
2003-04-28 14:17 ` Can ReiserFS solve this? 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
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=3EAD34D5.8030108@solidcode.net \
    --to=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.