[9fans] tarfs & 2GB limit

[9fans] tarfs & 2GB limit

[cej]

hi,

unfortunately, tarfs is apparently not able to mount >2GB tar files.
Do you think it could be fixed easily?

thanks,
++pac.

[9fans] tarfs & 2GB limit

[erik quanstrom]

this works for me on p9p. but the limit on tarball size is 1TB (512 bytes * 2GB).
i have not tested this for individual files in a tarball that are bigger than 2GB.

i've attached the diffs with the plan9 cd, excluding the p9p stuff.

- erik

; rcsdiff tapefs.h 
===================================================================
RCS file: RCS/tapefs.h,v
retrieving revision 1.1
diff -r1.1 tapefs.h
42c42
< 	long	ndata;
---
> 	vlong	ndata;
63c63
< 	long	size;
---
> 	vlong	size;
; rcsdiff tar*.c
===================================================================
RCS file: RCS/tarfs.c,v
retrieving revision 1.1
diff -r1.1 tarfs.c
38c38,39
< 	long blkno, isabs, chksum, linkflg;
---
> 	vlong blkno;
> 	long isabs, chksum, linkflg;
51c52
< 		f.addr = (void*)(blkno+1);
---
> 		f.addr = (void*)((ulong)blkno+1);
55c56
< 		f.size = strtoul(dblock.dbuf.size, 0, 8);
---
> 		f.size = strtoull(dblock.dbuf.size, 0, 8);
102c103
< 	seek(tapefile, (TBLOCK * (long)r->data)+off, 0);
---
> 	seek(tapefile, (TBLOCK * (vlong)r->data)+off, 0);

<cej@gli.cas.cz> writes

| 
| hi,
| 
| unfortunately, tarfs is apparently not able to mount >2GB tar files.
| Do you think it could be fixed easily?
| 
| thanks,
| ++pac.

Re: [9fans] tarfs & 2GB limit

[geoff]

The tar archive format limits archive members to 2⁳⁳ bytes = 8GB.
There are 11 octal digits for file size.  The current Plan 9 tar will
complain and refuse to add a file to a tar archive if its size exceeds
8GB-1.

The p9p tarfs is older than the Plan 9 one; in particular, the change
to cast seek's second argument to vlong is already in the Plan 9
tarfs, though not all of the other changes are.

Re: [9fans] tarfs & 2GB limit

[erik quanstrom]

there is no p9p tarfs. i keep a copy of (what i thought was)
an up-to-date plan9 dist here so i can easily grab stuff that hasn't 
been ported.

the 2GB filesize limit of tarfs is due to the long "off" passed 
to doread. i'm working on it.

- erik

geoff@collyer.net writes

| 
| The tar archive format limits archive members to 2⁳⁳ bytes = 8GB.
| There are 11 octal digits for file size.  The current Plan 9 tar will
| complain and refuse to add a file to a tar archive if its size exceeds
| 8GB-1.
| 
| The p9p tarfs is older than the Plan 9 one; in particular, the change
| to cast seek's second argument to vlong is already in the Plan 9
| tarfs, though not all of the other changes are.

Re: [9fans] tarfs & 2GB limit

[C H Forsyth]

51c52
< 		f.addr = (void*)(blkno+1);
---
> 		f.addr = (void*)((ulong)blkno+1);

it will be cleaner to have fileinf declare
	union {
		void*	addr;
		ulong	blockno;
	};
(or whatever is required) and use the right member of the union.
just say `no' to converting between void* and integers, when it's not essential.

Re: [9fans] tarfs & 2GB limit

[geoff]

Please make that

	union {
		void*	addr;
		uvlong	blockno;
	};

so that archives larger than 2TB can be made to work.

Re: [9fans] tarfs & 2GB limit

[erik quanstrom]

good point. i saw that problem and brain farted.
using the proper member of the union is also much better 
than the cast-o-rama.

- erik

geoff@collyer.net writes

| 
| Please make that
| 
| 	union {
| 		void*	addr;
| 		uvlong	blockno;
| 	};
| 
| so that archives larger than 2TB can be made to work.

Re: [9fans] tarfs & 2GB limit

[Devon H. O'Dell]

2006/1/13, C H Forsyth <forsyth@vitanuova.com>:
> 51c52
> <               f.addr = (void*)(blkno+1);
> ---
> >               f.addr = (void*)((ulong)blkno+1);
>
> it will be cleaner to have fileinf declare
>         union {
>                 void*   addr;
>                 ulong   blockno;
>         };
> (or whatever is required) and use the right member of the union.
> just say `no' to converting between void* and integers, when it's not essential.

Yes, this happens wayyyy too often. Since sizeof(int) and sizeof(void
*) are not the same on AMD64, there's even more reason to try to avoid
it.

--Devon

Re: [9fans] tarfs & 2GB limit

[Paul Lalonde]

And though it doesn't feel very plan9ish, I'm now going to sing the  
virtues of <inttypes.h>.
having standard sized integer types (int32_t, uint32_t, et al), along  
with intptr_t (an int that can hold any pointer) just makes too much  
sense, and adds information for the reader: you can be pretty sure  
you're mucking with addressing in an intptr_t; and that you need 16  
bits with a uint16_t.

If only converting old code with sizeof(int) == sizeof(int32_t) and  
sizeof(void *) == sizeof(int) assumptions weren't so time consuming :-(

Paul

On 13-Jan-06, at 4:33 PM, Devon H. O'Dell wrote:

> 2006/1/13, C H Forsyth <forsyth@vitanuova.com>:
>> 51c52
>> <               f.addr = (void*)(blkno+1);
>> ---
>>>               f.addr = (void*)((ulong)blkno+1);
>>
>> it will be cleaner to have fileinf declare
>>         union {
>>                 void*   addr;
>>                 ulong   blockno;
>>         };
>> (or whatever is required) and use the right member of the union.
>> just say `no' to converting between void* and integers, when it's  
>> not essential.
>
> Yes, this happens wayyyy too often. Since sizeof(int) and sizeof(void
> *) are not the same on AMD64, there's even more reason to try to avoid
> it.
>
> --Devon

Re: [9fans] tarfs & 2GB limit

[erik quanstrom]

already there: from p9p has the corrispondence in u.h:

typedef uint64_t u64int;
typedef int64_t s64int;
typedef uint8_t u8int;
typedef int8_t s8int;
typedef uint16_t u16int;
typedef int16_t s16int;
typedef uintptr_t uintptr;
typedef uint32_t u32int;
typedef int32_t s32int;

Paul Lalonde <plalonde@telus.net> writes

| 
| And though it doesn't feel very plan9ish, I'm now going to sing the  
| virtues of <inttypes.h>.
| having standard sized integer types (int32_t, uint32_t, et al), along  
| with intptr_t (an int that can hold any pointer) just makes too much  
| sense, and adds information for the reader: you can be pretty sure  
| you're mucking with addressing in an intptr_t; and that you need 16  
| bits with a uint16_t.
| 
| If only converting old code with sizeof(int) == sizeof(int32_t) and  
| sizeof(void *) == sizeof(int) assumptions weren't so time consuming :-(
| 
| Paul

[9fans] tarfs & 2GB limit

[erik quanstrom]

[-- Attachment #1: Type: text/plain, Size: 5820 bytes --]

i've been able to read tarballs >2G and read individual files >2G in tarballs
with these changes. i've also incorporated the suggested cleanup.

one question, with tpfs, there's a cast to vlong:
	seek(tapefile, 512*(vlong)r->data+off, 0);
i cast to (int) because the size is only 3 bytes.
is there anything drasticlly wrong with this?

- erik

./fs.c
108c108
< 	r->blockno = 0;
---
> 	r->data = 0;
406,407c406,407
< //	if(off > 100*1024*1024)		/* sanity check */
< //		return "write too big";
---
> 	if(off > 100*1024*1024)		/* sanity check */
> 		return "write too big";
=====================================================
./32vfs.c
106c106
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
109,117c109,112
< 	uvlong _bno;
< 	ulong bno;
< 	int i;
< 
< 	_bno = off/BLSIZE;
< 	off -= _bno*BLSIZE;
< 	bno = (ulong)bno;
< 	if (bno!=_bno)
< 		error("offset to large");
---
> 	int bno, i;
> 
> 	bno = off/BLSIZE;
> 	off -= bno*BLSIZE;
133c128
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./zipfs.c
33a34,41
> extern void populate(char *);
> extern void dotrunc(Ram *);
> extern void docreate(Ram *);
> extern char *doread(Ram *, long, long);
> extern void popdir(Ram *);
> extern void dowrite(Ram *, char *, long, long);
> extern int dopermw(Ram *);
> 
101c109
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
113c121
< 	if (Bseek(bin, r->blockno, 0) < 0)
---
> 	if (Bseek(bin, (uvlong)r->data & 0x7fffffff, 0) < 0)
142c150
< 			if (r->blockno & 0x80000000 && MUNGE_CR){
---
> 			if ((uvlong)r->data & 0x80000000 && MUNGE_CR){
165c173
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tapfs.c
95c95
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
99c99
< 	seek(tapefile, 512*(int)r->blockno+off, 0);
---
> 	seek(tapefile, 512*(vlong)r->data+off, 0);
105c105
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tarfs.c
38,39c38
< 	vlong blkno;
< 	long isabs, chksum, linkflg;
---
> 	long blkno, isabs, chksum, linkflg;
52c51
< 		f.blockno = blkno+1;
---
> 		f.addr = (void*)(blkno+1);
56c55
< 		f.size = strtoull(dblock.dbuf.size, 0, 8);
---
> 		f.size = strtoul(dblock.dbuf.size, 0, 8);
62c61
< 		||  strrchr(dblock.dbuf.name, '\0')[-1] == '/')
---
> 		||  strrchr(dblock.dbuf.name, '\0')[-1] == '/'){
63a63,64
> 			f.size = 0;
> 		}
69c70
< 			abort();
---
> 			exits("checksum");
100c101
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
103c104
< 	seek(tapefile, (TBLOCK * r->blockno)+off, 0);
---
> 	seek(tapefile, (TBLOCK * (vlong)r->data)+off, 0);
117c118
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)
132,133c133,134
< 	int i;
< 	char *cp;
---
> 	register i;
> 	register char *cp;

=====================================================
./cpiofs.c
39c39
< uvlong	getoct(char*, int);
---
> int	getoct(char*, int);
79c79
< 		f.blockno = (offset+sizeof(struct header)+namesize);
---
> 		f.addr = (void*)(offset+sizeof(struct header)+namesize);
87c87
< uvlong
---
> int
90c90
< 	uvlong r;
---
> 	int r;
112c112
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
115c115
< 	seek(tapefile, r->blockno+off, 0);
---
> 	seek(tapefile, (vlong)r->data+off, 0);
129c129
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./v6fs.c
107c107
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
129c129
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tpfs.c
20c20
< 	unsigned char	unused2[16];
---
> 	unsigned char	unused[16];
88c88
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
92c92
< 	seek(tapefile, 512*(int)r->blockno+off, 0);
---
> 	seek(tapefile, 512*(vlong)r->data+off, 0);
98c98
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./util.c
96c96
< 			ent->blockno = fi.blockno;
---
> 			ent->data = fi.addr;
133c133
< 	ent->blockno = fi.blockno;
---
> 	ent->data = fi.addr;

=====================================================
./tapefs.h
41,45c41,42
< 	union {
< 		void	*data;
< 		uvlong	blockno;
< 	};
< 	uvlong	ndata;
---
> 	void	*data;
> 	long	ndata;
65,69c62,63
< 	union {
< 		void	*addr;
< 		uvlong	blockno;
< 	};
< 	uvlong	size;
---
> 	void	*addr;
> 	long	size;
89,90c83,84
< char	*doread(Ram*, uvlong, long);
< void	dowrite(Ram*, char*, uvlong, long);
---
> char	*doread(Ram*, long, long);
> void	dowrite(Ram*, char*, long, long);
92c86
< Idmap	*_getpass(char*);
---
> Idmap	*getpass(char*);

=====================================================
./v10fs.c
106c106
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
109,113c109
< 	ulong bno;
< 	int i;
< 
< 	if (off>0xffffffff)
< 		error("offset too large");
---
> 	int bno, i;
132c128
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================

[-- Attachment #2: tapefs.diff --]
[-- Type: text/plain, Size: 5464 bytes --]

./fs.c
108c108
< 	r->blockno = 0;
---
> 	r->data = 0;
406,407c406,407
< //	if(off > 100*1024*1024)		/* sanity check */
< //		return "write too big";
---
> 	if(off > 100*1024*1024)		/* sanity check */
> 		return "write too big";
=====================================================
./32vfs.c
106c106
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
109,117c109,112
< 	uvlong _bno;
< 	ulong bno;
< 	int i;
< 
< 	_bno = off/BLSIZE;
< 	off -= _bno*BLSIZE;
< 	bno = (ulong)bno;
< 	if (bno!=_bno)
< 		error("offset to large");
---
> 	int bno, i;
> 
> 	bno = off/BLSIZE;
> 	off -= bno*BLSIZE;
133c128
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./zipfs.c
33a34,41
> extern void populate(char *);
> extern void dotrunc(Ram *);
> extern void docreate(Ram *);
> extern char *doread(Ram *, long, long);
> extern void popdir(Ram *);
> extern void dowrite(Ram *, char *, long, long);
> extern int dopermw(Ram *);
> 
101c109
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
113c121
< 	if (Bseek(bin, r->blockno, 0) < 0)
---
> 	if (Bseek(bin, (uvlong)r->data & 0x7fffffff, 0) < 0)
142c150
< 			if (r->blockno & 0x80000000 && MUNGE_CR){
---
> 			if ((uvlong)r->data & 0x80000000 && MUNGE_CR){
165c173
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tapfs.c
95c95
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
99c99
< 	seek(tapefile, 512*(int)r->blockno+off, 0);
---
> 	seek(tapefile, 512*(vlong)r->data+off, 0);
105c105
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tarfs.c
38,39c38
< 	vlong blkno;
< 	long isabs, chksum, linkflg;
---
> 	long blkno, isabs, chksum, linkflg;
52c51
< 		f.blockno = blkno+1;
---
> 		f.addr = (void*)(blkno+1);
56c55
< 		f.size = strtoull(dblock.dbuf.size, 0, 8);
---
> 		f.size = strtoul(dblock.dbuf.size, 0, 8);
62c61
< 		||  strrchr(dblock.dbuf.name, '\0')[-1] == '/')
---
> 		||  strrchr(dblock.dbuf.name, '\0')[-1] == '/'){
63a63,64
> 			f.size = 0;
> 		}
69c70
< 			abort();
---
> 			exits("checksum");
100c101
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
103c104
< 	seek(tapefile, (TBLOCK * r->blockno)+off, 0);
---
> 	seek(tapefile, (TBLOCK * (vlong)r->data)+off, 0);
117c118
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)
132,133c133,134
< 	int i;
< 	char *cp;
---
> 	register i;
> 	register char *cp;

=====================================================
./cpiofs.c
39c39
< uvlong	getoct(char*, int);
---
> int	getoct(char*, int);
79c79
< 		f.blockno = (offset+sizeof(struct header)+namesize);
---
> 		f.addr = (void*)(offset+sizeof(struct header)+namesize);
87c87
< uvlong
---
> int
90c90
< 	uvlong r;
---
> 	int r;
112c112
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
115c115
< 	seek(tapefile, r->blockno+off, 0);
---
> 	seek(tapefile, (vlong)r->data+off, 0);
129c129
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./v6fs.c
107c107
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
129c129
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./tpfs.c
20c20
< 	unsigned char	unused2[16];
---
> 	unsigned char	unused[16];
88c88
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
92c92
< 	seek(tapefile, 512*(int)r->blockno+off, 0);
---
> 	seek(tapefile, 512*(vlong)r->data+off, 0);
98c98
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================
./util.c
96c96
< 			ent->blockno = fi.blockno;
---
> 			ent->data = fi.addr;
133c133
< 	ent->blockno = fi.blockno;
---
> 	ent->data = fi.addr;

=====================================================
./tapefs.h
41,45c41,42
< 	union {
< 		void	*data;
< 		uvlong	blockno;
< 	};
< 	uvlong	ndata;
---
> 	void	*data;
> 	long	ndata;
65,69c62,63
< 	union {
< 		void	*addr;
< 		uvlong	blockno;
< 	};
< 	uvlong	size;
---
> 	void	*addr;
> 	long	size;
89,90c83,84
< char	*doread(Ram*, uvlong, long);
< void	dowrite(Ram*, char*, uvlong, long);
---
> char	*doread(Ram*, long, long);
> void	dowrite(Ram*, char*, long, long);
92c86
< Idmap	*_getpass(char*);
---
> Idmap	*getpass(char*);

=====================================================
./v10fs.c
106c106
< doread(Ram *r, uvlong off, long cnt)
---
> doread(Ram *r, long off, long cnt)
109,113c109
< 	ulong bno;
< 	int i;
< 
< 	if (off>0xffffffff)
< 		error("offset too large");
---
> 	int bno, i;
132c128
< dowrite(Ram *r, char *buf, uvlong off, long cnt)
---
> dowrite(Ram *r, char *buf, long off, long cnt)

=====================================================

Re: [9fans] tarfs & 2GB limit

[Russ Cox]

> one question, with tpfs, there's a cast to vlong:
>         seek(tapefile, 512*(vlong)r->data+off, 0);
> i cast to (int) because the size is only 3 bytes.
> is there anything drasticlly wrong with this?

the cast is there not because r->data is big,
but so that multiplying by 512 and adding
off doesn't overflow.

Re: [9fans] tarfs & 2GB limit

[erik quanstrom]

you're right, of course.

Russ Cox <rsc@swtch.com> writes

| 
| > one question, with tpfs, there's a cast to vlong:
| >         seek(tapefile, 512*(vlong)r->data+off, 0);
| > i cast to (int) because the size is only 3 bytes.
| > is there anything drasticlly wrong with this?
| 
| the cast is there not because r->data is big,
| but so that multiplying by 512 and adding
| off doesn't overflow.

Re: [9fans] tarfs & 2GB limit

[erik quanstrom]

you're right, of course.

Russ Cox <rsc@swtch.com> writes

| 
| > one question, with tpfs, there's a cast to vlong:
| >         seek(tapefile, 512*(vlong)r->data+off, 0);
| > i cast to (int) because the size is only 3 bytes.
| > is there anything drasticlly wrong with this?
| 
| the cast is there not because r->data is big,
| but so that multiplying by 512 and adding
| off doesn't overflow.
sendmail 9fans@cse.psu.edu rsc@swtch.com
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu,
	Russ Cox <rsc@swtch.com>
References: <ACCF003CBA3D09458207DB0CB86AD17D20153F@XMAIL.asuch.cas.cz>
	<20060113164151.ED27C35076@dexter-peak.quanstro.net>
	<20060114121550.4FD0134FFB@dexter-peak.quanstro.net>
	<ee9e417a0601141022g720dd846q6e1148d6100c95b6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <ee9e417a0601141022g720dd846q6e1148d6100c95b6@mail.gmail.com>
Subject: Re: [9fans] tarfs & 2GB limit

you're right, of course.

Russ Cox <rsc@swtch.com> writes

| 
| > one question, with tpfs, there's a cast to vlong:
| >         seek(tapefile, 512*(vlong)r->data+off, 0);
| > i cast to (int) because the size is only 3 bytes.
| > is there anything drasticlly wrong with this?
| 
| the cast is there not because r->data is big,
| but so that multiplying by 512 and adding
| off doesn't overflow.
sendmail anna@annabradshaw.com quanstro@quanstro.net
From: erik quanstrom <quanstro@quanstro.net>
To: Anna Bradshaw <anna@annabradshaw.com>,
	erik quanstrom <quanstro@quanstro.net>
References: <BFED25BA.3B5B%timothy-barrett@uiowa.edu>
	<2872A7CE-AE8D-4B03-A3F5-A2D291CF6B1A@annabradshaw.com>
	<20060113173158.EF72835076@dexter-peak.quanstro.net>
	<B0445687-0DC1-4B1B-B8E3-C9A914223558@annabradshaw.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <B0445687-0DC1-4B1B-B8E3-C9A914223558@annabradshaw.com>
Subject: Re: bug steals the show

i'm sure it's a bug in the mailer. computers. you can't live with 'em, you ....

- erik

Anna Bradshaw <anna@annabradshaw.com> writes

| 
| I just sent them like I always do.  The comment was the subject  
| line.  Not sure what happened exactly.
| 
| 
sendmail anna@annabradshaw.com quanstro@quanstro.net
From: erik quanstrom <quanstro@quanstro.net>
To: Anna Bradshaw <anna@annabradshaw.com>,
	erik quanstrom <quanstro@quanstro.net>
References: <BFED25BA.3B5B%timothy-barrett@uiowa.edu>
	<2872A7CE-AE8D-4B03-A3F5-A2D291CF6B1A@annabradshaw.com>
	<20060113173158.EF72835076@dexter-peak.quanstro.net>
	<B0445687-0DC1-4B1B-B8E3-C9A914223558@annabradshaw.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <B0445687-0DC1-4B1B-B8E3-C9A914223558@annabradshaw.com>
Subject: Re: bug steals the show

i'm sure it's a bug in the mailer. computers. you can't live with 'em, you ....

- erik

Anna Bradshaw <anna@annabradshaw.com> writes

| 
| I just sent them like I always do.  The comment was the subject  
| line.  Not sure what happened exactly.
| 
| 
sendmail lucio@proxima.alt.za quanstro@quanstro.net
From: erik quanstrom <quanstro@quanstro.net>
To: lucio@proxima.alt.za,
	quanstro@quanstro.net
References: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Subject: Re: [9fans] warning of putchar

it's a good stop-gap. i'm pretty sure the hueristics like this do
not work, in general.

the most consistant indicator of spam is the structure of the 
Recieved lines. unfortunately, i have yet to figure out how to
write a set of rules for recieved lines that's 85% effective.

maybe the real problem is that spam is like porn. "i know it when
i see it." ;-)

- erik

lucio@proxima.alt.za writes

| 
| > there is recourse. run your own mailserver. i blew some power
| > supplies, i've been using the third-in-line server, which i don't 
| > control.
| 
| Ah, that explains it.  My approach to spam curbing consists of dumping
| unknowns to a folder in Cape Town and forwarding to my home only
| summary headers.  Occasionally, I spot mail from a desired source,
| otherwise I check the folder on a whim.
| 
| It's not ideal, but it does diminish my frustration level without
| depriving me of important mail.  Now to figure out how to use the
| notification as a remote mechanism to prompt forwarding or discrding.
| 
| ++L
sendmail lucio@proxima.alt.za quanstro@quanstro.net
From: erik quanstrom <quanstro@quanstro.net>
To: lucio@proxima.alt.za,
	quanstro@quanstro.net
References: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Subject: Re: [9fans] warning of putchar

it's a good stop-gap. i'm pretty sure the hueristics like this do
not work, in general.

the most consistant indicator of spam is the structure of the 
Recieved lines. unfortunately, i have yet to figure out how to
write a set of rules for recieved lines that's 85% effective.

maybe the real problem is that spam is like porn. "i know it when
i see it." ;-)

- erik

lucio@proxima.alt.za writes

| 
| > there is recourse. run your own mailserver. i blew some power
| > supplies, i've been using the third-in-line server, which i don't 
| > control.
| 
| Ah, that explains it.  My approach to spam curbing consists of dumping
| unknowns to a folder in Cape Town and forwarding to my home only
| summary headers.  Occasionally, I spot mail from a desired source,
| otherwise I check the folder on a whim.
| 
| It's not ideal, but it does diminish my frustration level without
| depriving me of important mail.  Now to figure out how to use the
| notification as a remote mechanism to prompt forwarding or discrding.
| 
| ++L
sendmail lucio@proxima.alt.za quanstro@quanstro.net
From: erik quanstrom <quanstro@quanstro.net>
To: lucio@proxima.alt.za,
	quanstro@quanstro.net
References: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
In-Reply-To: <a75cdbce8f12d43125d85da97b6aa622@proxima.alt.za>
Subject: Re: [9fans] warning of putchar

it's a good stop-gap. i'm pretty sure the hueristics like this do
not work, in general.

the most consistant indicator of spam is the structure of the 
Recieved lines. unfortunately, i have yet to figure out how to
write a set of rules for recieved lines that's 85% effective.

maybe the real problem is that spam is like porn. "i know it when
i see it." ;-)

- erik

lucio@proxima.alt.za writes

| 
| > there is recourse. run your own mailserver. i blew some power
| > supplies, i've been using the third-in-line server, which i don't 
| > control.
| 
| Ah, that explains it.  My approach to spam curbing consists of dumping
| unknowns to a folder in Cape Town and forwarding to my home only
| summary headers.  Occasionally, I spot mail from a desired source,
| otherwise I check the folder on a whim.
| 
| It's not ideal, but it does diminish my frustration level without
| depriving me of important mail.  Now to figure out how to use the
| notification as a remote mechanism to prompt forwarding or discrding.
| 
| ++L