From: Erik Terpstra <erik@solidcode.net>
Cc: reiserfs-list@namesys.com
Subject: Re: Can ReiserFS solve this?
Date: Mon, 28 Apr 2003 16:26:52 +0200 [thread overview]
Message-ID: <3EAD3A2C.4070509@solidcode.net> (raw)
In-Reply-To: <200304281417.h3SEHudA003449@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
>On Mon, 28 Apr 2003 16:04:05 +0200, Erik Terpstra <erik@solidcode.net> said:
>
>
>>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.
>>
>>
>
>Note that *any* solution has to deal elegantly with the case of a transfer
>that fails partway through. No amount of 'fuser' or reiser trickery will
>fix the case where you are receiving a 400mb TIFF, and the connection is
>closed after 250M is transferred.
>
I agree, but shouldn't it be possible to see a distinction between files
that are actually there and those that are coming in?
From my problem domain there are three cases:
1) Files that are arriving
2) Files that have arrived and are complete (i.e. correct TIFF format)
3) Files that have arrived and are incomplete (invalid TIFFs)
I am happy to deal with case 2 and 3, but I am not interested in case 1.
If my problem domain is not related to filesystems then that's okay, but
I appreciate your opinion (I am not a filesystem expert).
Erik.
next prev parent reply other threads:[~2003-04-28 14:26 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 [this message]
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=3EAD3A2C.4070509@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.