Re: [94] [Libbt-devel] Re: Need some "other than Mac" checking done
Brought to you by:
ksmathers
From: <ke...@an...> - 2005-05-13 21:02:29
|
> Op donderdag 5 mei 2005 23:38, schreef Dakidd: > > I've also done some cleanup and rewiring in the cacheopen() routine - > > You'll notice that the "mode" and "options" parameters have been renamed - > > Those two drove me absolutely *NUTS* until I finally broke down and > > "hand-executed" the code. The names were hideously confusing, and once I > > got through things, it became clear that Kevin had screwed the pooch > > bigtime - "options" gets passed in only when setting up a "writeable" file, > > and is the Unix file-access permission setting that should be used when the > > file is created. As it was coded, it was being stored as one of the things > > to look at for deciding whether the file was open and cached or not. *BIG* > > screwup! It's obvious (now that I've "hand-executed" it) from looking at > > the rest of the routine that the intention was to open/cache a file based > > on its name and whether it was opened for read or write mode. Checking > > against the file permissions is pointless, and was the source of some major > > hair-pulling as I tried to figure out why nothing I did would make the > > routine work as expected on a Mac. This forced changes to the cache > > struct/array (c_fileset), and some rewriting of the code that worked with > > it. cacheopen() follows the signature of open(), see 'util.h'. You have the meanings of options and mode reversed. Mode is for unix permissions (cf open), and options is the local variable name in cacheopen() for what is called 'flags' as a parameter to open (O_WRONLY, O_RDONLY, O_CREAT, etc.) I should make it consistent with open and use 'flags' here, but there is history to the variable 'options' and it would take a while to untangle it. Cacheopen() is just a front-end to open that keeps the number of open file descriptors to within some reasonable limit. Originally I used to keep all of the files open simultaneously, but that could quickly overwhelm the limits in ulimit.h for a torrent with thousands of files embedded. I've double checked the parameter order, and the mode and flags parameters are in the correct order in each call, so I don't see how you could have gotten the mode parameter into the options parameter (or vice versa.) It certainly doesn't do that in my code. -- Look ma, no threads[1]. [1] BitTorrent in C is http://www.sf.net/projects/libbt // .--=, .....::://::::::::::::::::::::::::::::.. (o O & ke...@an... :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ |