* [9fans] tarfs & 2GB limit @ 2006-01-13 14:11 cej 2006-01-13 16:41 ` erik quanstrom 0 siblings, 1 reply; 14+ messages in thread From: cej @ 2006-01-13 14:11 UTC (permalink / raw) To: 9fans hi, unfortunately, tarfs is apparently not able to mount >2GB tar files. Do you think it could be fixed easily? thanks, ++pac. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [9fans] tarfs & 2GB limit 2006-01-13 14:11 [9fans] tarfs & 2GB limit cej @ 2006-01-13 16:41 ` erik quanstrom 2006-01-13 22:33 ` geoff ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-13 16:41 UTC (permalink / raw) To: 9fans, cej 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 16:41 ` erik quanstrom @ 2006-01-13 22:33 ` geoff 2006-01-14 0:30 ` erik quanstrom 2006-01-13 22:36 ` C H Forsyth 2006-01-14 12:15 ` erik quanstrom 2 siblings, 1 reply; 14+ messages in thread From: geoff @ 2006-01-13 22:33 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 22:33 ` geoff @ 2006-01-14 0:30 ` erik quanstrom 0 siblings, 0 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-14 0:30 UTC (permalink / raw) To: 9fans, geoff 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 16:41 ` erik quanstrom 2006-01-13 22:33 ` geoff @ 2006-01-13 22:36 ` C H Forsyth 2006-01-13 22:43 ` geoff 2006-01-14 0:33 ` Devon H. O'Dell 2006-01-14 12:15 ` erik quanstrom 2 siblings, 2 replies; 14+ messages in thread From: C H Forsyth @ 2006-01-13 22:36 UTC (permalink / raw) To: quanstro, 9fans 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 22:36 ` C H Forsyth @ 2006-01-13 22:43 ` geoff 2006-01-14 0:03 ` erik quanstrom 2006-01-14 0:33 ` Devon H. O'Dell 1 sibling, 1 reply; 14+ messages in thread From: geoff @ 2006-01-13 22:43 UTC (permalink / raw) To: 9fans Please make that union { void* addr; uvlong blockno; }; so that archives larger than 2TB can be made to work. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 22:43 ` geoff @ 2006-01-14 0:03 ` erik quanstrom 0 siblings, 0 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-14 0:03 UTC (permalink / raw) To: 9fans, geoff 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-13 22:36 ` C H Forsyth 2006-01-13 22:43 ` geoff @ 2006-01-14 0:33 ` Devon H. O'Dell 2006-01-14 0:59 ` Paul Lalonde 1 sibling, 1 reply; 14+ messages in thread From: Devon H. O'Dell @ 2006-01-14 0:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-14 0:33 ` Devon H. O'Dell @ 2006-01-14 0:59 ` Paul Lalonde 2006-01-14 1:07 ` erik quanstrom 0 siblings, 1 reply; 14+ messages in thread From: Paul Lalonde @ 2006-01-14 0:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-14 0:59 ` Paul Lalonde @ 2006-01-14 1:07 ` erik quanstrom 0 siblings, 0 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-14 1:07 UTC (permalink / raw) To: 9fans, Paul Lalonde 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [9fans] tarfs & 2GB limit 2006-01-13 16:41 ` erik quanstrom 2006-01-13 22:33 ` geoff 2006-01-13 22:36 ` C H Forsyth @ 2006-01-14 12:15 ` erik quanstrom 2006-01-14 18:22 ` Russ Cox 2 siblings, 1 reply; 14+ messages in thread From: erik quanstrom @ 2006-01-14 12:15 UTC (permalink / raw) To: 9fans, cej, 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) ===================================================== ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-14 12:15 ` erik quanstrom @ 2006-01-14 18:22 ` Russ Cox 2006-01-14 21:27 ` erik quanstrom 2006-01-16 2:57 ` erik quanstrom 0 siblings, 2 replies; 14+ messages in thread From: Russ Cox @ 2006-01-14 18:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-14 18:22 ` Russ Cox @ 2006-01-14 21:27 ` erik quanstrom 2006-01-16 2:57 ` erik quanstrom 1 sibling, 0 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-14 21:27 UTC (permalink / raw) To: 9fans, Russ Cox 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9fans] tarfs & 2GB limit 2006-01-14 18:22 ` Russ Cox 2006-01-14 21:27 ` erik quanstrom @ 2006-01-16 2:57 ` erik quanstrom 1 sibling, 0 replies; 14+ messages in thread From: erik quanstrom @ 2006-01-16 2:57 UTC (permalink / raw) To: 9fans, Russ Cox 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-01-16 2:57 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-13 14:11 [9fans] tarfs & 2GB limit cej 2006-01-13 16:41 ` erik quanstrom 2006-01-13 22:33 ` geoff 2006-01-14 0:30 ` erik quanstrom 2006-01-13 22:36 ` C H Forsyth 2006-01-13 22:43 ` geoff 2006-01-14 0:03 ` erik quanstrom 2006-01-14 0:33 ` Devon H. O'Dell 2006-01-14 0:59 ` Paul Lalonde 2006-01-14 1:07 ` erik quanstrom 2006-01-14 12:15 ` erik quanstrom 2006-01-14 18:22 ` Russ Cox 2006-01-14 21:27 ` erik quanstrom 2006-01-16 2:57 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).