Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.vms > #58251 > unrolled thread
| Started by | helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) |
|---|---|
| First post | 2016-06-12 19:04 +0000 |
| Last post | 2016-06-17 10:39 +0200 |
| Articles | 20 on this page of 338 — 25 participants |
Back to article view | Back to comp.os.vms
FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 19:04 +0000
Re: FREESPADRIFT Johnny Billquist <bqt@softjar.se> - 2016-06-12 21:17 +0200
Re: FREESPADRIFT Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:01 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 20:23 +0000
Re: FREESPADRIFT Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-12 20:36 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-14 09:02 +0000
Re: FREESPADRIFT helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-12 20:22 +0000
Re: FREESPADRIFT Johnny Billquist <bqt@softjar.se> - 2016-06-13 11:45 +0200
Re: FREESPADRIFT "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-12 16:08 -0400
Re: FREESPADRIFT brendan welch <w1lpg@uml.edu> - 2016-06-12 17:20 -0400
Re: FREESPADRIFT koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-13 09:20 -0400
Re: FREESPADRIFT lawrencedo99@gmail.com - 2016-06-14 18:42 -0700
Re: FREESPADRIFT moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-16 18:24 +0000
Re: FREESPADRIFT "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-16 15:15 -0400
Re: FREESPADRIFT lawrencedo99@gmail.com - 2016-06-16 16:01 -0700
Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-16 19:56 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-16 17:23 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-16 21:16 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-16 20:11 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-17 10:26 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-17 15:28 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-18 00:39 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Michael Moroney <moroney@TheWorld.com> - 2016-06-17 22:41 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-17 23:14 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-17 20:10 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 10:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 02:19 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 13:51 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-18 14:31 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 15:24 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-18 22:57 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 20:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Kerry Main <kerry.main@backtothefutureit.com> - 2016-06-19 01:46 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 10:56 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 11:32 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:42 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:00 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:12 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 22:45 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:29 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:50 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-18 14:48 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-18 21:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 11:26 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 22:55 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:38 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-21 14:53 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-21 16:18 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-21 18:27 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:34 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-21 17:07 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 12:36 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 16:47 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 16:06 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 18:33 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 14:46 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:16 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-26 19:33 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:23 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:42 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:58 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:40 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:03 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:19 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:39 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 16:55 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:36 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:43 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:20 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:33 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-28 09:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:48 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:59 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:06 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 17:05 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 14:50 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:24 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:34 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 22:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-24 08:52 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-24 16:54 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-24 13:41 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-24 18:27 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 13:33 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:14 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:50 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:02 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:35 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:26 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:15 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 09:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 16:15 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:23 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:42 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 16:56 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 19:41 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:09 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:41 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 14:43 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 22:18 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:08 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 14:53 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:17 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:16 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:31 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:22 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 19:27 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 21:55 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-23 22:15 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-24 10:50 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) - 2016-06-24 11:19 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:12 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-23 21:17 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 15:08 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 17:34 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-27 13:40 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 20:21 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 20:28 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 22:38 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 21:29 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 23:40 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-27 22:39 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:32 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 12:15 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 14:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 13:45 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 15:58 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-29 14:07 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 16:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-07-11 09:34 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-07-11 11:31 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-11 20:48 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-07-11 15:49 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-12 13:03 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-11 20:47 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-29 11:01 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 12:48 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 15:12 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 15:15 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 17:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 18:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 17:00 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 21:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 19:38 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 14:19 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-07-01 12:58 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 17:42 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 17:03 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-30 15:17 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-30 20:02 +0000
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-29 10:51 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) johnwallace4@yahoo.co.uk - 2016-06-27 21:09 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-27 23:39 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:44 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 10:47 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-19 19:47 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 07:38 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-19 22:46 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 11:41 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 03:13 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:13 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 16:55 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-21 10:18 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-21 07:29 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Paul Sture <nospam@sture.ch> - 2016-06-20 17:38 +0200
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) lawrencedo99@gmail.com - 2016-06-20 17:01 -0700
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 08:34 -0400
Re: BACKUP, rsync, Time Machine (was: Re: Re; Spiralog, RMS Journaling...) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-20 07:40 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-22 00:27 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 09:43 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-22 12:36 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:27 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-23 12:49 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-24 03:03 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-27 15:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-27 15:51 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 10:56 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-29 02:41 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 11:54 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-29 03:04 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-29 12:57 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-30 00:15 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-30 14:51 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-30 15:37 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-01 14:14 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-02 17:38 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-04 15:04 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-05 15:02 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-05 15:09 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-07-04 12:30 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 09:45 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-18 20:07 +0200
RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-18 18:41 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 18:50 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:48 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-18 19:56 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 23:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 09:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:20 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 14:18 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 15:03 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-19 15:49 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 11:46 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 23:26 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:07 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 06:47 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 09:54 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) hb <end.of@inter.net> - 2016-06-20 17:37 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 10:47 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) hb <end.of@inter.net> - 2016-06-20 21:28 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-20 13:27 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-20 10:19 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) VAXman- @SendSpamHere.ORG - 2016-06-20 14:39 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 11:14 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 12:30 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-20 20:39 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 22:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-20 22:15 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-21 00:57 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Steven Schweda <sms.antinode@gmail.com> - 2016-06-20 19:42 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-20 23:06 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-20 12:27 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-20 14:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-21 09:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-21 07:16 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was John Reagan <xyzzy1959@gmail.com> - 2016-06-21 07:44 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-21 15:02 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-21 15:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-22 12:10 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-22 09:53 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-22 20:25 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 16:18 -0400
System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:49 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-23 12:26 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-23 18:44 +0200
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-23 12:43 -0500
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-23 14:40 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-26 19:29 -0700
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-27 13:03 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-27 09:09 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-27 14:54 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-23 18:59 +0000
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 17:04 -0400
Re: System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Chris Scheers <chris@applied-synergy.com> - 2016-06-24 14:54 -0500
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:41 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 12:45 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Anderson <paul.anderson@vmssoftware.com> - 2016-06-22 17:03 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2016-06-22 19:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "-------------------------Michael W. Farrell" <mfarrell001@verizon.net> - 2016-06-23 01:10 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 16:16 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was "Craig A. Berry" <craigberry@nospam.mac.com> - 2016-06-22 22:04 -0500
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-23 07:52 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:02 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-23 12:16 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-21 17:58 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-21 13:05 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-22 12:27 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was VAXman- @SendSpamHere.ORG - 2016-06-22 12:46 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-22 20:42 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-22 10:15 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-21 15:04 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 14:11 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 19:50 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 17:57 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 08:35 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was hb <end.of@inter.net> - 2016-06-23 15:18 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-23 09:46 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was hb <end.of@inter.net> - 2016-06-23 16:10 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:56 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-25 14:47 -0400
MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 19:44 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 02:16 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Paul Sture <nospam@sture.ch> - 2016-06-26 10:26 +0200
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:23 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 22:30 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 11:20 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-26 12:43 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:34 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:10 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-27 00:46 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 03:16 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-26 19:41 -0700
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-27 17:39 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-27 15:44 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:09 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 22:23 +0000
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-26 10:07 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 11:30 -0400
Re: MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:30 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 08:59 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Johnny Billquist <bqt@softjar.se> - 2016-06-23 16:40 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:05 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-22 15:00 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 01:40 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-23 00:18 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 10:10 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-23 01:50 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-23 11:03 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-22 19:57 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was koehler@eisner.nospam.decuserve.org (Bob Koehler) - 2016-06-23 09:00 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was lawrencedo99@gmail.com - 2016-06-24 03:54 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-24 21:24 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 12:43 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-25 12:52 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-25 21:37 +0200
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was David Froble <davef@tsoft-inc.com> - 2016-06-26 02:07 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:47 -0400
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-19 14:40 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-06-19 20:14 -0700
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-20 19:19 +0000
Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-06-19 21:29 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 15:02 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) John Reagan <xyzzy1959@gmail.com> - 2016-06-18 13:59 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-18 19:12 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-18 22:57 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Stephen Hoffman <seaohveh@hoffmanlabs.invalid> - 2016-06-19 12:03 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) David Froble <davef@tsoft-inc.com> - 2016-06-19 23:35 -0400
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Johnny Billquist <bqt@softjar.se> - 2016-06-21 18:01 +0200
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) "John E. Malmberg" <wb8tyw@qsl.net_work> - 2016-06-18 12:52 -0500
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) lawrencedo99@gmail.com - 2016-07-04 15:05 -0700
Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) Paul Sture <nospam@sture.ch> - 2016-07-04 19:11 +0200
Re: FREESPADRIFT moroney@world.std.spaamtrap.com (Michael Moroney) - 2016-06-17 02:57 +0000
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 07:24 +0200
Re: FREESPADRIFT David Froble <davef@tsoft-inc.com> - 2016-06-17 02:28 -0400
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 16:56 +0200
Re: FREESPADRIFT David Froble <davef@tsoft-inc.com> - 2016-06-17 13:22 -0400
Re: FREESPADRIFT Paul Sture <nospam@sture.ch> - 2016-06-17 20:53 +0200
Re: FREESPADRIFT "Kerry Main" <kemain.nospam@gmail.com> - 2016-06-17 15:22 -0400
Re: FREESPADRIFT Jan-Erik Soderholm <jan-erik.soderholm@telia.com> - 2016-06-17 10:39 +0200
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-18 18:50 -0700 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <e8ed1c5b-b2e6-41e3-84d9-1c9417e72474@googlegroups.com> |
| In reply to | #58548 |
On Sunday, June 19, 2016 at 6:35:05 AM UTC+12, Kerry Main wrote: > With OpenVMS and its default write-through strategies, data integrity > has always been the primary driver. I fully accept that. And I, too, deplore vendor strategies that prioritize good-looking benchmarks over data integrity. Particularly insidious are hard drives with on-board cache, where a request to “make sure you really, really write this data to disk” can be met with “OK, I really, really have done it” right down to the SATA interface level, only to have the data still sitting in some controller cache buffer, not really on the disk at all, so it could still be lost on the next power failure. Filesystem journalling is a way of improving your confidence in the integrity of the volume structure across crashes. So instead of doing a fsck (MOUNT/VERIFY?) on every reboot, you can defer that to, say, once every six months (I think that’s what the Linux systems usually do).
[toc] | [prev] | [next] | [standalone]
| From | "Kerry Main" <kemain.nospam@gmail.com> |
|---|---|
| Date | 2016-06-18 14:48 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <mailman.318.1466275752.14919.info-vax_rbnsn.com@rbnsn.com> |
| In reply to | #58542 |
> -----Original Message----- > From: Info-vax [mailto:info-vax-bounces@rbnsn.com] On Behalf Of Paul > Sture via Info-vax > Sent: 18-Jun-16 7:52 AM > To: info-vax@rbnsn.com > Cc: Paul Sture <nospam@sture.ch> > Subject: Re: [Info-vax] Re; Spiralog, RMS Journaling (was Re: > FREESPADRIFT) > [snip] > > >> cf VMS only storing the block sizes of files rather than the number of > >> bytes; this can be problematic for utilities ported from a system which > >> has an easy/cheap way to supply the exact size in bytes. > > > > This was the example Linus Torvalds gave of why he hated VMS... > > Eh? There are many reasons to dislike an OS but 'hating VMS' for that > *perceived* problem? Really? > Btw, it's not that well known, but while the default display of file size and device free space is blocks, with OpenVMS, you can also get these values in bytes as well. >From V8.4-2 system: SYS003> dir sys$system:sysdump.dmp/siz=all Directory SYS$SYSROOT:[SYSEXE] SYSDUMP.DMP;1 1604596/1604608 Total of 1 file, 1604596/1604608 blocks. SYS003> set proc/unit=bytes SYS003> dir sys$system:sysdump.dmp/siz=all Directory SYS$SYSROOT:[SYSEXE] SYSDUMP.DMP;1 783.49MB/783.50MB Total of 1 file, 783.49MB/783.50MB SYS003> sho dev dsa20 Device Device Error Volume Free Trans Mnt Name Status Count Label Space Count Cnt DSA20: Mounted 0 USER2 1.66TB 51 1 $1$DKC1: (SYS003) ShadowSetMember 0 (member of DSA20:) SYS003> Regards, Kerry Main Kerry dot main at starkgaming dot com
[toc] | [prev] | [next] | [standalone]
| From | Jan-Erik Soderholm <jan-erik.soderholm@telia.com> |
|---|---|
| Date | 2016-06-18 21:19 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nk46so$ijf$1@news.albasani.net> |
| In reply to | #58550 |
Den 2016-06-18 kl. 20:48, skrev Kerry Main: >> -----Original Message----- >> From: Info-vax [mailto:info-vax-bounces@rbnsn.com] On Behalf Of Paul >> Sture via Info-vax >> Sent: 18-Jun-16 7:52 AM >> To: info-vax@rbnsn.com >> Cc: Paul Sture <nospam@sture.ch> >> Subject: Re: [Info-vax] Re; Spiralog, RMS Journaling (was Re: >> FREESPADRIFT) >> > [snip] > >> >>>> cf VMS only storing the block sizes of files rather than the number > of >>>> bytes; this can be problematic for utilities ported from a system > which >>>> has an easy/cheap way to supply the exact size in bytes. >>> >>> This was the example Linus Torvalds gave of why he hated VMS... >> >> Eh? There are many reasons to dislike an OS but 'hating VMS' for that >> *perceived* problem? Really? >> > > Btw, it's not that well known, but while the default display of file > size and > device free space is blocks, with OpenVMS, you can also get these values > > in bytes as well. Yes, but that is a simple calculation with 1 block = 512 bytes. It does not correctly display partially filled blocks. I guess that what most here are talking about is the size up to the marker. Convering the used/allocated number of blocks is simple. Jan-Erik.
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-18 22:35 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nk50d4$fmu$2@dont-email.me> |
| In reply to | #58552 |
Jan-Erik Soderholm wrote: > Den 2016-06-18 kl. 20:48, skrev Kerry Main: >>> -----Original Message----- >>> From: Info-vax [mailto:info-vax-bounces@rbnsn.com] On Behalf Of Paul >>> Sture via Info-vax >>> Sent: 18-Jun-16 7:52 AM >>> To: info-vax@rbnsn.com >>> Cc: Paul Sture <nospam@sture.ch> >>> Subject: Re: [Info-vax] Re; Spiralog, RMS Journaling (was Re: >>> FREESPADRIFT) >>> >> [snip] >> >>> >>>>> cf VMS only storing the block sizes of files rather than the number >> of >>>>> bytes; this can be problematic for utilities ported from a system >> which >>>>> has an easy/cheap way to supply the exact size in bytes. >>>> >>>> This was the example Linus Torvalds gave of why he hated VMS... >>> >>> Eh? There are many reasons to dislike an OS but 'hating VMS' for that >>> *perceived* problem? Really? >>> >> >> Btw, it's not that well known, but while the default display of file >> size and >> device free space is blocks, with OpenVMS, you can also get these values >> >> in bytes as well. > > Yes, but that is a simple calculation with 1 block = 512 bytes. > It does not correctly display partially filled blocks. I guess > that what most here are talking about is the size up to the > marker. Convering the used/allocated number of blocks is simple. > > Jan-Erik. I would suggest "what does it matter?" It's not like some other file is going to use the unused portion of some disk block, or, as suggested, unused part of 4096 bytes ....
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hoffman <seaohveh@hoffmanlabs.invalid> |
|---|---|
| Date | 2016-06-19 11:26 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nk6dji$gmg$1@dont-email.me> |
| In reply to | #58567 |
On 2016-06-19 02:35:16 +0000, David Froble said: > I would suggest "what does it matter?" > > It's not like some other file is going to use the unused portion of > some disk block, or, as suggested, unused part of 4096 bytes .... If I'm mapping the user data into memory, having its size is useful. Otherwise, I slog through RMS records or such. If I'm messing with disk allocations and more directly managing storage — something I'd prefer to avoid, but that can arise on OpenVMS and other systems — then the total size of the file including all user data and all of its overhead and/or pre-allocation and/or metadata is of interest. This is akin to UTF-8, where you might be looking for the numbers of glyphs in the string, or for the size of the required memory buffer to store the string. Many OpenVMS apps simply don't have the concept of mapping the entire file into memory, they assume datasets far larger than available memory and/or comparatively weak and slow paging I/O support, and for those apps the total data size wasn't really a factor. They're written to deal with records. (This is also where the overhead of dealing with zillions of small hunks via RMS — and not a few and larger hunks — can become a run-time performance-limiting factor.) For apps that map whole files or that map masses of data into memory, the user dataset size (modulo any virtual memory allocation granularity in play) tends to matter more, unless those apps are implementing their own paging — as various databases do. Defining data structures and allowing the run-time system to pack and unpack records for the app is a concept that largely doesn't exist on OpenVMS. You have to roll your own (glue) code to do that. -- Pure Personal Opinion | HoffmanLabs LLC
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-19 22:55 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nk7lv1$em0$1@dont-email.me> |
| In reply to | #58607 |
Stephen Hoffman wrote: > On 2016-06-19 02:35:16 +0000, David Froble said: > >> I would suggest "what does it matter?" >> >> It's not like some other file is going to use the unused portion of >> some disk block, or, as suggested, unused part of 4096 bytes .... > > If I'm mapping the user data into memory, having its size is useful. > Otherwise, I slog through RMS records or such. Agreed. Wasn't thinking about things like that. And I've never done that, so it's understandable I would not have considered it. > If I'm messing with disk allocations and more directly managing storage > — something I'd prefer to avoid, but that can arise on OpenVMS and other > systems — then the total size of the file including all user data and > all of its overhead and/or pre-allocation and/or metadata is of interest. Agreed. > This is akin to UTF-8, where you might be looking for the numbers of > glyphs in the string, or for the size of the required memory buffer to > store the string. Don't have such experience, but you're correct. > Many OpenVMS apps simply don't have the concept of mapping the entire > file into memory, they assume datasets far larger than available memory > and/or comparatively weak and slow paging I/O support, and for those > apps the total data size wasn't really a factor. They're written to > deal with records. (This is also where the overhead of dealing with > zillions of small hunks via RMS — and not a few and larger hunks — can > become a run-time performance-limiting factor.) For apps that map whole > files or that map masses of data into memory, the user dataset size > (modulo any virtual memory allocation granularity in play) tends to > matter more, unless those apps are implementing their own paging — as > various databases do. > > Defining data structures and allowing the run-time system to pack and > unpack records for the app is a concept that largely doesn't exist on > OpenVMS. You have to roll your own (glue) code to do that. Yep, did that long ago .... Still works well, but, I would not recommend it vs today's database products. You give good examples, I've just never seen any of those examples.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-21 17:38 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkbn1q$5cn$2@Iltempo.Update.UU.SE> |
| In reply to | #58567 |
On 2016-06-19 04:35, David Froble wrote: > Jan-Erik Soderholm wrote: >> Yes, but that is a simple calculation with 1 block = 512 bytes. >> It does not correctly display partially filled blocks. I guess >> that what most here are talking about is the size up to the >> marker. Convering the used/allocated number of blocks is simple. >> >> Jan-Erik. > > I would suggest "what does it matter?" > > It's not like some other file is going to use the unused portion of some > disk block, or, as suggested, unused part of 4096 bytes .... No. But if you implement FTP, or a web server, or any number of other tools/programs, they are expected to report file sizes in bytes, and the byte count should be *accurate*. Even one byte off is not acceptable. And that becomes costly if your system do not keep that information, and you have to calculate it yourself. Johnny
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-21 14:53 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkc2eu$cgp$2@dont-email.me> |
| In reply to | #58718 |
Johnny Billquist wrote: > On 2016-06-19 04:35, David Froble wrote: >> Jan-Erik Soderholm wrote: > >>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>> It does not correctly display partially filled blocks. I guess >>> that what most here are talking about is the size up to the >>> marker. Convering the used/allocated number of blocks is simple. >>> >>> Jan-Erik. >> >> I would suggest "what does it matter?" >> >> It's not like some other file is going to use the unused portion of some >> disk block, or, as suggested, unused part of 4096 bytes .... > > No. But if you implement FTP, or a web server, or any number of other > tools/programs, they are expected to report file sizes in bytes, and the > byte count should be *accurate*. Even one byte off is not acceptable. > And that becomes costly if your system do not keep that information, and > you have to calculate it yourself. > > Johnny > I've done some communications in the past. I usually use a handshake similar to: Sender> Hey, I've got x bytes to send to you Receiver> Ok, go ahead Sender> sends string Receiver> Ok, got x bytes If any of the above goes South, then start over from the beginning With timeouts, of course .. So, yes, I understand.
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-21 16:18 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0AF3F.7FE01F54@SendSpamHere.ORG> |
| In reply to | #58567 |
In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2016-06-19 04:35, David Froble wrote:
>> Jan-Erik Soderholm wrote:
>
>>> Yes, but that is a simple calculation with 1 block = 512 bytes.
>>> It does not correctly display partially filled blocks. I guess
>>> that what most here are talking about is the size up to the
>>> marker. Convering the used/allocated number of blocks is simple.
>>>
>>> Jan-Erik.
>>
>> I would suggest "what does it matter?"
>>
>> It's not like some other file is going to use the unused portion of some
>> disk block, or, as suggested, unused part of 4096 bytes ....
>
>No. But if you implement FTP, or a web server, or any number of other
>tools/programs, they are expected to report file sizes in bytes, and the
>byte count should be *accurate*. Even one byte off is not acceptable.
Why?
>And that becomes costly if your system do not keep that information, and
>you have to calculate it yourself.
$ SEARCH file.txt ""/NOOUTPUT/STATISTICS
Files searched: 1 Buffered I/O count: 5
Records searched: 255 Direct I/O count: 1
Characters searched: 11333 --. Page faults: 20
Records matched: 255 | Elapsed CPU time: 0 00:00:00.00
Lines printed: 0 | Elapsed time: 0 00:00:00.00
`---------------.
$ DUMP/HEADER/BLOCKS=COUNT=0 file.txt |
: |
: |
Highest block: 32 |
End of file block: 24 |
End of file byte: 220 |
: |
: |
File length hints |
Record count: 255 |
Data byte count: 11333 <---'
:
:
(24-1)+220 => 11996
Which is right? 11333? 11996? Neither?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Jan-Erik Soderholm <jan-erik.soderholm@telia.com> |
|---|---|
| Date | 2016-06-21 18:27 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkbpti$i3$1@news.albasani.net> |
| In reply to | #58723 |
Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: > In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-19 04:35, David Froble wrote: >>> Jan-Erik Soderholm wrote: >> >>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>> It does not correctly display partially filled blocks. I guess >>>> that what most here are talking about is the size up to the >>>> marker. Convering the used/allocated number of blocks is simple. >>>> >>>> Jan-Erik. >>> >>> I would suggest "what does it matter?" >>> >>> It's not like some other file is going to use the unused portion of some >>> disk block, or, as suggested, unused part of 4096 bytes .... >> >> No. But if you implement FTP, or a web server, or any number of other >> tools/programs, they are expected to report file sizes in bytes, and the >> byte count should be *accurate*. Even one byte off is not acceptable. > A web server probably always has to calculate the number of bytes sent to get it right. There is many ways that the sent data can be different then the on-file data and the web page can be "dynamic". > Why? In HTTP you can end up with connections staying open and waiting for that final byte that never comes.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-21 18:40 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkbql2$dqk$1@Iltempo.Update.UU.SE> |
| In reply to | #58725 |
On 2016-06-21 18:27, Jan-Erik Soderholm wrote: > Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> On 2016-06-19 04:35, David Froble wrote: >>>> Jan-Erik Soderholm wrote: >>> >>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>> It does not correctly display partially filled blocks. I guess >>>>> that what most here are talking about is the size up to the >>>>> marker. Convering the used/allocated number of blocks is simple. >>>>> >>>>> Jan-Erik. >>>> >>>> I would suggest "what does it matter?" >>>> >>>> It's not like some other file is going to use the unused portion of >>>> some >>>> disk block, or, as suggested, unused part of 4096 bytes .... >>> >>> No. But if you implement FTP, or a web server, or any number of other >>> tools/programs, they are expected to report file sizes in bytes, and the >>> byte count should be *accurate*. Even one byte off is not acceptable. >> > > A web server probably always has to calculate the number of bytes > sent to get it right. There is many ways that the sent data can be > different then the on-file data and the web page can be "dynamic". It don't have to tell the size. But if you don't, you need to then either encode the transfer in a way that can indicate the transfer is complete, or close the connection at the end, to indicate that the transfer is complete. HTTO 1.0 didn't have any encoding trick, so there you had to close the connection, which is costly. Also, without size information, you will not get any progress bars, or estimated time remaining. The browser will just show that it is working, and that is all you will know... FTP is supposed to always be able to tell the correct size. The RFC also points out that on some systems, this can be very costly, so it shouldn't be requested lightheartedly. But Unix systems violate this both in calling it way more often, and also lying about the size. >> Why? > > In HTTP you can end up with connections staying open and > waiting for that final byte that never comes. Yup. If you lie about the size, bad things will happen. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-21 18:34 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkbqbl$d5l$1@Iltempo.Update.UU.SE> |
| In reply to | #58723 |
On 2016-06-21 18:18, VAXman-@SendSpamHere.ORG wrote: > In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-19 04:35, David Froble wrote: >>> Jan-Erik Soderholm wrote: >> >>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>> It does not correctly display partially filled blocks. I guess >>>> that what most here are talking about is the size up to the >>>> marker. Convering the used/allocated number of blocks is simple. >>>> >>>> Jan-Erik. >>> >>> I would suggest "what does it matter?" >>> >>> It's not like some other file is going to use the unused portion of some >>> disk block, or, as suggested, unused part of 4096 bytes .... >> >> No. But if you implement FTP, or a web server, or any number of other >> tools/programs, they are expected to report file sizes in bytes, and the >> byte count should be *accurate*. Even one byte off is not acceptable. > > Why? Because the frickin' protocol specs say so? :-) And because other software then assumes that if the spec says so, then they can rely on it, and consequently will only read that many bytes before considering the transfer to be complete. If you then send fewer bytes than you claimed the size was, the other end will wait until the end of time for those additional bytes to put into the receiving end. And if you actually send more bytes, then the receiver will ignore them. Either way, if it's actually a transfer of a file, the file on the other end will end up not having the same content. I don't know about you, but around here, that is considered to be a broken transfer... >> And that becomes costly if your system do not keep that information, and >> you have to calculate it yourself. > > $ SEARCH file.txt ""/NOOUTPUT/STATISTICS > > Files searched: 1 Buffered I/O count: 5 > Records searched: 255 Direct I/O count: 1 > Characters searched: 11333 --. Page faults: 20 > Records matched: 255 | Elapsed CPU time: 0 00:00:00.00 > Lines printed: 0 | Elapsed time: 0 00:00:00.00 > `---------------. > $ DUMP/HEADER/BLOCKS=COUNT=0 file.txt | > : | > : | > Highest block: 32 | > End of file block: 24 | > End of file byte: 220 | > : | > : | > File length hints | > Record count: 255 | > Data byte count: 11333 <---' > : > : > > (24-1)+220 => 11996 > > Which is right? 11333? 11996? Neither? Are you asking me? :-) It would, of course, depend on what you actually want to know... Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-21 17:07 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0AF46.642167BC@SendSpamHere.ORG> |
| In reply to | #58723 |
In article <nkbpti$i3$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes: >Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-19 04:35, David Froble wrote: >>>> Jan-Erik Soderholm wrote: >>> >>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>> It does not correctly display partially filled blocks. I guess >>>>> that what most here are talking about is the size up to the >>>>> marker. Convering the used/allocated number of blocks is simple. >>>>> >>>>> Jan-Erik. >>>> >>>> I would suggest "what does it matter?" >>>> >>>> It's not like some other file is going to use the unused portion of some >>>> disk block, or, as suggested, unused part of 4096 bytes .... >>> >>> No. But if you implement FTP, or a web server, or any number of other >>> tools/programs, they are expected to report file sizes in bytes, and the >>> byte count should be *accurate*. Even one byte off is not acceptable. >> > >A web server probably always has to calculate the number of bytes >sent to get it right. There is many ways that the sent data can be >different then the on-file data and the web page can be "dynamic". > >> Why? > >In HTTP you can end up with connections staying open and >waiting for that final byte that never comes. Exactly! And you answered the 'Why?' prior to the quoted first instance. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 12:19 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkgd41$2g9$1@Iltempo.Update.UU.SE> |
| In reply to | #58731 |
On 2016-06-21 19:07, VAXman-@SendSpamHere.ORG wrote: > In article <nkbpti$i3$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes: >> Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >>> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>> On 2016-06-19 04:35, David Froble wrote: >>>>> Jan-Erik Soderholm wrote: >>>> >>>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>>> It does not correctly display partially filled blocks. I guess >>>>>> that what most here are talking about is the size up to the >>>>>> marker. Convering the used/allocated number of blocks is simple. >>>>>> >>>>>> Jan-Erik. >>>>> >>>>> I would suggest "what does it matter?" >>>>> >>>>> It's not like some other file is going to use the unused portion of some >>>>> disk block, or, as suggested, unused part of 4096 bytes .... >>>> >>>> No. But if you implement FTP, or a web server, or any number of other >>>> tools/programs, they are expected to report file sizes in bytes, and the >>>> byte count should be *accurate*. Even one byte off is not acceptable. >>> >> >> A web server probably always has to calculate the number of bytes >> sent to get it right. There is many ways that the sent data can be >> different then the on-file data and the web page can be "dynamic". >> >>> Why? >> >> In HTTP you can end up with connections staying open and >> waiting for that final byte that never comes. > > Exactly! And you answered the 'Why?' prior to the quoted first instance. I don't get your point. I'm saying that the reported file size has to be correct to the byte, and we're talking about data bytes here. Actual content. Calculating a file size based on blocks totally do not cut it, as that will include meta-data, and will possibly exclude actual data, so the size will not be accurate. And I pointed out that it has to be accurate, since the protocols says so, and programs work under this assumption. So what did you mean with that comment? Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 12:36 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0B2.CFA80708@SendSpamHere.ORG> |
| In reply to | #58731 |
In article <nkgd41$2g9$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-21 19:07, VAXman-@SendSpamHere.ORG wrote: >> In article <nkbpti$i3$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes: >>> Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >>>> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2016-06-19 04:35, David Froble wrote: >>>>>> Jan-Erik Soderholm wrote: >>>>> >>>>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>>>> It does not correctly display partially filled blocks. I guess >>>>>>> that what most here are talking about is the size up to the >>>>>>> marker. Convering the used/allocated number of blocks is simple. >>>>>>> >>>>>>> Jan-Erik. >>>>>> >>>>>> I would suggest "what does it matter?" >>>>>> >>>>>> It's not like some other file is going to use the unused portion of some >>>>>> disk block, or, as suggested, unused part of 4096 bytes .... >>>>> >>>>> No. But if you implement FTP, or a web server, or any number of other >>>>> tools/programs, they are expected to report file sizes in bytes, and the >>>>> byte count should be *accurate*. Even one byte off is not acceptable. >>>> >>> >>> A web server probably always has to calculate the number of bytes >>> sent to get it right. There is many ways that the sent data can be >>> different then the on-file data and the web page can be "dynamic". >>> >>>> Why? >>> >>> In HTTP you can end up with connections staying open and >>> waiting for that final byte that never comes. >> >> Exactly! And you answered the 'Why?' prior to the quoted first instance. > >I don't get your point. I'm saying that the reported file size has to be >correct to the byte, and we're talking about data bytes here. Actual >content. Calculating a file size based on blocks totally do not cut it, >as that will include meta-data, and will possibly exclude actual data, >so the size will not be accurate. > >And I pointed out that it has to be accurate, since the protocols says >so, and programs work under this assumption. > >So what did you mean with that comment? It's important to that protocol or others, but not to VMS. The sizes reported on VMS are concerned only with storage consumption. That size may or may not reflect what is seen when VMS presents that data to you. In your protocol(s), it may be important to count a <CR> and or <LF> that's sent if the data is text based. Those <CR>s and <LF>s don't necessarily have to exist in the on disk stored file. You could, for example, $ TYPE out an indexed file and get/see text representation of all of its records. On the disk, there's more than that -- for keyed access to the records -- that you'll not see in the output. In addition, those records are, more likely than not, compressed; therefore, all that is seen if you $ TYPE that file does NOT necessarily exist within the data stored on the storage device. So, if your protocol needs an exact size, then you'd better count it. If VMS doesn't need it -- and I just outlined why it doesn't have it -- then why should it have to provide it? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 16:47 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkgspt$rm$2@Iltempo.Update.UU.SE> |
| In reply to | #58835 |
On 2016-06-23 14:36, VAXman-@SendSpamHere.ORG wrote: > In article <nkgd41$2g9$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> On 2016-06-21 19:07, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkbpti$i3$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes: >>>> Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >>>>> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>> On 2016-06-19 04:35, David Froble wrote: >>>>>>> Jan-Erik Soderholm wrote: >>>>>> >>>>>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>>>>> It does not correctly display partially filled blocks. I guess >>>>>>>> that what most here are talking about is the size up to the >>>>>>>> marker. Convering the used/allocated number of blocks is simple. >>>>>>>> >>>>>>>> Jan-Erik. >>>>>>> >>>>>>> I would suggest "what does it matter?" >>>>>>> >>>>>>> It's not like some other file is going to use the unused portion of some >>>>>>> disk block, or, as suggested, unused part of 4096 bytes .... >>>>>> >>>>>> No. But if you implement FTP, or a web server, or any number of other >>>>>> tools/programs, they are expected to report file sizes in bytes, and the >>>>>> byte count should be *accurate*. Even one byte off is not acceptable. >>>>> >>>> >>>> A web server probably always has to calculate the number of bytes >>>> sent to get it right. There is many ways that the sent data can be >>>> different then the on-file data and the web page can be "dynamic". >>>> >>>>> Why? >>>> >>>> In HTTP you can end up with connections staying open and >>>> waiting for that final byte that never comes. >>> >>> Exactly! And you answered the 'Why?' prior to the quoted first instance. >> >> I don't get your point. I'm saying that the reported file size has to be >> correct to the byte, and we're talking about data bytes here. Actual >> content. Calculating a file size based on blocks totally do not cut it, >> as that will include meta-data, and will possibly exclude actual data, >> so the size will not be accurate. >> >> And I pointed out that it has to be accurate, since the protocols says >> so, and programs work under this assumption. >> >> So what did you mean with that comment? > > > It's important to that protocol or others, but not to VMS. The sizes reported on VMS > are concerned only with storage consumption. That size may or may not reflect what is > seen when VMS presents that data to you. In your protocol(s), it may be important to > count a <CR> and or <LF> that's sent if the data is text based. Those <CR>s and <LF>s > don't necessarily have to exist in the on disk stored file. You could, for example, > $ TYPE out an indexed file and get/see text representation of all of its records. On > the disk, there's more than that -- for keyed access to the records -- that you'll not > see in the output. In addition, those records are, more likely than not, compressed; > therefore, all that is seen if you $ TYPE that file does NOT necessarily exist within > the data stored on the storage device. > > So, if your protocol needs an exact size, then you'd better count it. If VMS doesn't > need it -- and I just outlined why it doesn't have it -- then why should it have to > provide it? This whole thread came about because some people pointed out that exact file sizes, to the byte, sometimes were wanted. And then it's been a thread of "why?". And when I give an example of why, it becomes a thread of "why?". Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, writing an http server (as well as an ftp server), do care. And doing these things, which many people consider to be pretty basic tools that all systems should have, is a pain because the file system do not have this information. Yes, there are solutions. They are costly. Could there possibly be a point in adding this information, if it can be done at a low cost? You are just putting your head in the sand and saying that since it's not there, we don't need it. Johnny
[toc] | [prev] | [next] | [standalone]
| From | VAXman- @SendSpamHere.ORG |
|---|---|
| Date | 2016-06-23 16:06 +0000 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <00B0B0D0.1687A67A@SendSpamHere.ORG> |
| In reply to | #58835 |
In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >On 2016-06-23 14:36, VAXman-@SendSpamHere.ORG wrote: >> In article <nkgd41$2g9$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>> On 2016-06-21 19:07, VAXman-@SendSpamHere.ORG wrote: >>>> In article <nkbpti$i3$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes: >>>>> Den 2016-06-21 kl. 18:18, skrev VAXman-@SendSpamHere.ORG: >>>>>> In article <nkbn1q$5cn$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >>>>>>> On 2016-06-19 04:35, David Froble wrote: >>>>>>>> Jan-Erik Soderholm wrote: >>>>>>> >>>>>>>>> Yes, but that is a simple calculation with 1 block = 512 bytes. >>>>>>>>> It does not correctly display partially filled blocks. I guess >>>>>>>>> that what most here are talking about is the size up to the >>>>>>>>> marker. Convering the used/allocated number of blocks is simple. >>>>>>>>> >>>>>>>>> Jan-Erik. >>>>>>>> >>>>>>>> I would suggest "what does it matter?" >>>>>>>> >>>>>>>> It's not like some other file is going to use the unused portion of some >>>>>>>> disk block, or, as suggested, unused part of 4096 bytes .... >>>>>>> >>>>>>> No. But if you implement FTP, or a web server, or any number of other >>>>>>> tools/programs, they are expected to report file sizes in bytes, and the >>>>>>> byte count should be *accurate*. Even one byte off is not acceptable. >>>>>> >>>>> >>>>> A web server probably always has to calculate the number of bytes >>>>> sent to get it right. There is many ways that the sent data can be >>>>> different then the on-file data and the web page can be "dynamic". >>>>> >>>>>> Why? >>>>> >>>>> In HTTP you can end up with connections staying open and >>>>> waiting for that final byte that never comes. >>>> >>>> Exactly! And you answered the 'Why?' prior to the quoted first instance. >>> >>> I don't get your point. I'm saying that the reported file size has to be >>> correct to the byte, and we're talking about data bytes here. Actual >>> content. Calculating a file size based on blocks totally do not cut it, >>> as that will include meta-data, and will possibly exclude actual data, >>> so the size will not be accurate. >>> >>> And I pointed out that it has to be accurate, since the protocols says >>> so, and programs work under this assumption. >>> >>> So what did you mean with that comment? >> >> >> It's important to that protocol or others, but not to VMS. The sizes reported on VMS >> are concerned only with storage consumption. That size may or may not reflect what is >> seen when VMS presents that data to you. In your protocol(s), it may be important to >> count a <CR> and or <LF> that's sent if the data is text based. Those <CR>s and <LF>s >> don't necessarily have to exist in the on disk stored file. You could, for example, >> $ TYPE out an indexed file and get/see text representation of all of its records. On >> the disk, there's more than that -- for keyed access to the records -- that you'll not >> see in the output. In addition, those records are, more likely than not, compressed; >> therefore, all that is seen if you $ TYPE that file does NOT necessarily exist within >> the data stored on the storage device. >> >> So, if your protocol needs an exact size, then you'd better count it. If VMS doesn't >> need it -- and I just outlined why it doesn't have it -- then why should it have to >> provide it? > >This whole thread came about because some people pointed out that exact >file sizes, to the byte, sometimes were wanted. And then it's been a >thread of "why?". And when I give an example of why, it becomes a thread >of "why?". > >Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >writing an http server (as well as an ftp server), do care. And doing >these things, which many people consider to be pretty basic tools that >all systems should have, is a pain because the file system do not have >this information. > >Yes, there are solutions. They are costly. Could there possibly be a >point in adding this information, if it can be done at a low cost? > >You are just putting your head in the sand and saying that since it's >not there, we don't need it. Why pay for it when you don't need it? Pay for it when you do! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 18:33 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkh313$ekh$1@Iltempo.Update.UU.SE> |
| In reply to | #58850 |
On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: > In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes: >> This whole thread came about because some people pointed out that exact >> file sizes, to the byte, sometimes were wanted. And then it's been a >> thread of "why?". And when I give an example of why, it becomes a thread >> of "why?". >> >> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >> writing an http server (as well as an ftp server), do care. And doing >> these things, which many people consider to be pretty basic tools that >> all systems should have, is a pain because the file system do not have >> this information. >> >> Yes, there are solutions. They are costly. Could there possibly be a >> point in adding this information, if it can be done at a low cost? >> >> You are just putting your head in the sand and saying that since it's >> not there, we don't need it. > > Why pay for it when you don't need it? Pay for it when you do! Which, for a web server, is every time a document is requested, which might mean a dozen requests for a single page. And that is just one example. And for a 10M document, calculating the size every time is pretty costly... Reading through 10M to find the size, and then read through it again, to deliver it. Color me not-excited. Johnny
[toc] | [prev] | [next] | [standalone]
| From | David Froble <davef@tsoft-inc.com> |
|---|---|
| Date | 2016-06-23 14:46 -0400 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhaqu$5la$2@dont-email.me> |
| In reply to | #58852 |
Johnny Billquist wrote: > On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: >> In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist >> <bqt@softjar.se> writes: >>> This whole thread came about because some people pointed out that exact >>> file sizes, to the byte, sometimes were wanted. And then it's been a >>> thread of "why?". And when I give an example of why, it becomes a thread >>> of "why?". >>> >>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >>> writing an http server (as well as an ftp server), do care. And doing >>> these things, which many people consider to be pretty basic tools that >>> all systems should have, is a pain because the file system do not have >>> this information. >>> >>> Yes, there are solutions. They are costly. Could there possibly be a >>> point in adding this information, if it can be done at a low cost? >>> >>> You are just putting your head in the sand and saying that since it's >>> not there, we don't need it. >> >> Why pay for it when you don't need it? Pay for it when you do! > > Which, for a web server, is every time a document is requested, which > might mean a dozen requests for a single page. And that is just one > example. And for a 10M document, calculating the size every time is > pretty costly... Reading through 10M to find the size, and then read > through it again, to deliver it. Color me not-excited. > > Johnny > Why would you read through it twice? With a few exceptions, read it into memory, then transmit it. Something you got to do anyway. Perhaps just re-ordering the task. Too big? Got to ask, what's wrong with doing things in segments? Maybe not how the *ix world does things. Who's to say they are always right?
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2016-06-23 21:16 +0200 |
| Subject | Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT) |
| Message-ID | <nkhcik$1o0$1@Iltempo.Update.UU.SE> |
| In reply to | #58860 |
On 2016-06-23 20:46, David Froble wrote: > Johnny Billquist wrote: >> On 2016-06-23 18:06, VAXman-@SendSpamHere.ORG wrote: >>> In article <nkgspt$rm$2@Iltempo.Update.UU.SE>, Johnny Billquist >>> <bqt@softjar.se> writes: >>>> This whole thread came about because some people pointed out that exact >>>> file sizes, to the byte, sometimes were wanted. And then it's been a >>>> thread of "why?". And when I give an example of why, it becomes a >>>> thread >>>> of "why?". >>>> >>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me, >>>> writing an http server (as well as an ftp server), do care. And doing >>>> these things, which many people consider to be pretty basic tools that >>>> all systems should have, is a pain because the file system do not have >>>> this information. >>>> >>>> Yes, there are solutions. They are costly. Could there possibly be a >>>> point in adding this information, if it can be done at a low cost? >>>> >>>> You are just putting your head in the sand and saying that since it's >>>> not there, we don't need it. >>> >>> Why pay for it when you don't need it? Pay for it when you do! >> >> Which, for a web server, is every time a document is requested, which >> might mean a dozen requests for a single page. And that is just one >> example. And for a 10M document, calculating the size every time is >> pretty costly... Reading through 10M to find the size, and then read >> through it again, to deliver it. Color me not-excited. >> >> Johnny >> > > Why would you read through it twice? With a few exceptions, read it > into memory, then transmit it. Something you got to do anyway. Perhaps > just re-ordering the task. > > Too big? Got to ask, what's wrong with doing things in segments? Maybe > not how the *ix world does things. Who's to say they are always right? I think you missed the point. For a web server, you *have* to give the size before you start sending data. Doing it in segments then obviously is not the answer. Nor is reordering of anything. Size comes first, data comes after. Do I have to repeat it again? And blaming Unix isn't useful/meaningful either. The protocol is that way. Deal with it. And yes, it can be too big to just gob into memory, not to mention that gobbing many megs of memory for this is a pretty poor design. Johnny
[toc] | [prev] | [next] | [standalone]
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
Back to top | Article view | comp.os.vms
csiph-web