From: Andrew S. <an...@ne...> - 2001-02-07 12:06:31
|
> Author : cpk > Project : e17 > Module : apps/efsd [...] > - /* We're whimp's here and just exit. */ > + /* We're whimps here and just exit. */ Actually, there's no 'h' in wimps. =) Andrew. -- Andrew Shugg <an...@ne...> http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." |
From: Alan S. <ala...@in...> - 2001-02-21 08:24:01
|
Solved all the efsd problems here. Just need to figure out why e17 suddenly decides to segv (right in the middle of looking at my home dir: .. Stat event 38 stating file /home/schmitta/go /home/schmitta/go is a directory. Stat event 40 stating file /home/schmitta/site-lisp /home/schmitta/site-lisp is a directory. Stat event 41 stating file /home/schmitta/settlers /home/schmitta/settlers is a directory. Stat event 42 stating file /home/schmitta/research /home/schmitta/reseEEEEEEEEK SEGV - waiting 10 seconds EEEEEEEEK SEGV - waiting 10 seconds EEEEEEEEK SEGV - waiting 10 seconds ) (guess it's time to learn how to bt ;-) Alan >Enlightenment CVS committal > >Author : cpk >Project : e17 >Module : apps/efsd > >Dir : e17/apps/efsd/efsd > > >Modified Files: > efsd_io.c > > >Log Message: >Of course write()s can see EAGAIN errors too ... > -- The hacker: someone who figured things out and made something cool happen. |
From: <ra...@ra...> - 2001-02-21 09:02:59
|
On 21 Feb, Alan Schmitt scribbled: -> Solved all the efsd problems here. -> -> Just need to figure out why e17 suddenly decides to segv (right in the -> middle of looking at my home dir: -> -> .. -> Stat event 38 stating file /home/schmitta/go -> /home/schmitta/go is a directory. -> Stat event 40 stating file /home/schmitta/site-lisp -> /home/schmitta/site-lisp is a directory. -> Stat event 41 stating file /home/schmitta/settlers -> /home/schmitta/settlers is a directory. -> Stat event 42 stating file /home/schmitta/research -> /home/schmitta/reseEEEEEEEEK SEGV - waiting 10 seconds -> EEEEEEEEK SEGV - waiting 10 seconds -> EEEEEEEEK SEGV - waiting 10 seconds -> ) it *SHOULDNT* - bt would be nice? and a list and variable dump of approprisate variables (depends where it dumps tho) -> (guess it's time to learn how to bt ;-) -> -> Alan -> -> >Enlightenment CVS committal -> > -> >Author : cpk -> >Project : e17 -> >Module : apps/efsd -> > -> >Dir : e17/apps/efsd/efsd -> > -> > -> >Modified Files: -> > efsd_io.c -> > -> > -> >Log Message: -> >Of course write()s can see EAGAIN errors too ... -> > -> -> -> -- -> The hacker: someone who figured things out and made something cool happen. -> -> _______________________________________________ -> Enlightenment-devel mailing list -> Enl...@li... -> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |
From: Peter K. <pet...@ax...> - 2001-03-24 09:27:29
|
> -----Original Message----- > From: enl...@li... > [mailto:enl...@li...] > Sent: Saturday, March 24, 2001 01:59 > To: enl...@so... > Subject: E CVS: apps/efsd cpk > > > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > > Modified Files: > efsd_fam.c efsd_main.c > > > Log Message: > Hah! Raster, try and see if this helps ... > > =================================================================== > RCS file: /cvsroot/enlightenment/e17/apps/efsd/efsd/efsd_main.c,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -3 -r1.4 -r1.5 > --- efsd_main.c 2001/03/23 00:45:42 1.4 > +++ efsd_main.c 2001/03/24 00:59:28 1.5 > @@ -179,8 +179,10 @@ > > D_ENTER; > > + bzero(&ec, sizeof(EfsdCommand)); > ec.efsd_file_cmd.file = filename; > ec.efsd_file_cmd.id = efr->id; > + ec.efsd_file_cmd.num_options = 0; > > for (i = 0; i < efr->num_options; i++) > { Minor nitpicking I guess, but bzero() is considered deprecated. Use memset() instead (all according to the man page :) //Peter |
From: Jens T. <tap...@id...> - 2001-04-03 10:01:33
|
On Fri, Mar 30, 2001 at 10:41:21AM -0800, enl...@li... wrote: > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > > Modified Files: > Makefile.am efsd.h efsd_fam.c efsd_fam.h efsd_fileops.c > efsd_fileops.h efsd_globals.h efsd_io.c efsd_list.c > efsd_list.h efsd_main.c efsd_meta.c efsd_misc.c efsd_options.c > efsd_options.h efsd_types.c libefsd.c libefsd.h > Added Files: > efsd_filetype.c efsd_filetype.h efsd_hash.c efsd_hash.h > efsd_statcache.c efsd_statcache.h > Removed Files: > efsd_magic.c efsd_magic.h > > > Log Message: > Introducing a generic hash facility and caching systems for stats > and filetypes. I think I fixed a couple of bugs along the way, but > I haven't tested this much. It's probably a good idea to look at > this from a good distance ... Efsd is segfaulting on my machine since these changes tool place. Here is the gdb output: Program received signal SIGSEGV, Segmentation fault. 0x4004b73d in __os_calloc () from /usr/lib/libedb.so.1 (gdb) backtrace #0 0x4004b73d in __os_calloc () from /usr/lib/libedb.so.1 #1 0x40247b77 in db_create () from /usr/lib/libdb3.so.3 #2 0x401efd62 in db_open () from /lib/libnss_db.so.2 #3 0x401efe60 in internal_setent () from /lib/libnss_db.so.2 #4 0x401ef12e in _nss_db_endrpcent () from /lib/libnss_db.so.2 #5 0x401ef398 in _nss_db_getrpcbyname_r () from /lib/libnss_db.so.2 #6 0x4014ef1f in getrpcbyname_r () from /lib/libc.so.6 #7 0x4014ea6d in getrpcbyname () from /lib/libc.so.6 #8 0x4006b4bc in FAMOpen2 () from /usr/lib/libfam.so.0 #9 0x4006b60c in FAMOpen () from /usr/lib/libfam.so.0 #10 0x804bc4f in geteuid () #11 0x8051009 in geteuid () #12 0x4008e16b in __libc_start_main () from /lib/libc.so.6 I hope this helps. Jens |
From: <ra...@ra...> - 2001-04-07 18:40:55
|
On 7 Apr, enl...@li... scribbled: > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > > Modified Files: > efsd_statcache.c libefsd.c libefsd.h > > > Log Message: > I've changed the way of passing options, because using variadic functions > is way too painful when one has to put options together dynamically at > runtime (let's say you're passing combinations of 5 options -- you get > 2^5 different calls :). > > So now I leave it up to the user to put things together manually (efsdsh > does this), or using a variadic convenience wrapper like this: and now.... :) efsdsh.c: In function `command_line': efsdsh.c:347: `EfsdOptions' undeclared (first use in this function) efsdsh.c:347: (Each undeclared identifier is reported only once efsdsh.c:347: for each function it appears in.) efsdsh.c:347: `ops' undeclared (first use in this function) efsdsh.c:347: invalid lvalue in assignment i'll fix it.. done.. :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 |
From: Andrew S. <an...@ne...> - 2001-07-18 15:37:04
|
> Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/doc/figures > > > Added Files: > efsd-event.eps efsd-event.fig efsd-event.gif > Removed Files: > union.eps union.fig union.gif > > > Log Message: > That was a stupid name. > That's what I thought, but then thought "nah he knows what he's doing!" =) Andrew. -- Andrew Shugg <an...@ne...> http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." |
From: Christian K. <kre...@in...> - 2001-07-18 17:53:42
|
Andrew Shugg wrote: > > > Author : cpk > > Project : e17 > > Module : apps/efsd > > > > Dir : e17/apps/efsd/doc/figures > > > > > > Added Files: > > efsd-event.eps efsd-event.fig efsd-event.gif > > Removed Files: > > union.eps union.fig union.gif > > > > > > Log Message: > > That was a stupid name. > > > > That's what I thought, but then thought "nah he knows what he's doing!" =) I am! Always! Really! :o) -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Carsten H. (T. R. <ra...@ra...> - 2001-08-03 08:20:38
|
On Wed, 01 Aug 2001 01:53:04 -0700 enl...@li... babbled profusely: > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > > Modified Files: > efsd_commands.c efsd_hash.c efsd_types.c libefsd.c > > > Log Message: > > NORTY NORTY NORTY! > > Yup, that's me! :) > > > were all returning 0! :) fix one.. i'm sure there are others... > > Erm .. why? Funny, those cleanups are still from the time when we had that > odd bug I didn't see and you did, remember? Anyway, I forgot to clean up > in efsd_chmod(), and called FREE() twice on options (didn't do any > harm). Also fixed some warnings. hmmm maybe that was it.. well fornow it's working ok. no major probs i've seen today in my travails... i know my meta data return handling is awful.. i need to break it out into a function... but for today it works... :) yay! > Btw, Raster: metadata handling, especially when moving/copying files, > has seen little testing. Handle with care :) oh i understand that... i was expecting it to not work at all.. but it worked.. once i fixed the cmd_id return problem... i see you went and fixed another one or 2 in your commit :) excellent :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +61 (0)408 363 984 Work Phone: +61 (02) 9386 9362 |
From: Christian K. <kre...@in...> - 2001-08-03 08:41:52
|
"Carsten Haitzler (The Rasterman)" wrote: > > hmmm maybe that was it.. well fornow it's working ok. no major probs i've seen > today in my travails... i know my meta data return handling is awful.. i need to > break it out into a function... but for today it works... :) yay! Aaaah happy cK :) > > Btw, Raster: metadata handling, especially when moving/copying files, > > has seen little testing. Handle with care :) > > oh i understand that... i was expecting it to not work at all.. but it worked.. > once i fixed the cmd_id return problem... i see you went and fixed another one > or 2 in your commit :) excellent :) Yeah, I've also played with moving and copying files etc and metatdata should be treated correctly ... we'll see. Btw do you have any news about the kernel metadata patch you mentioned? Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Carsten H. (T. R. <ra...@ra...> - 2001-08-17 01:01:25
|
On Thu, 16 Aug 2001 17:47:45 -0700 enl...@li... babbled profusely: > Log Message: > Oooh the options do get cleaned up, but not their container :) > Raster, does this fix it? yup. fixed :) tnx! :) > =================================================================== > RCS file: /cvsroot/enlightenment/e17/apps/efsd/efsd/libefsd.c,v > retrieving revision 1.48 > retrieving revision 1.49 > diff -u -3 -r1.48 -r1.49 > --- libefsd.c 2001/08/01 08:53:04 1.48 > +++ libefsd.c 2001/08/17 00:47:45 1.49 > @@ -415,6 +415,8 @@ > result = file_cmd(ec, EFSD_CMD_REMOVE, num_files, files, ops->num_used, > ops->ops); > else > result = file_cmd(ec, EFSD_CMD_REMOVE, num_files, files, 0, NULL); > + > + FREE(ops); > > D_RETURN_(result); > } > @@ -431,6 +433,8 @@ > result = file_cmd(ec, EFSD_CMD_MOVE, num_files, files, ops->num_used, > ops->ops); > else > result = file_cmd(ec, EFSD_CMD_MOVE, num_files, files, 0, NULL); > + > + FREE(ops); > > D_RETURN_(result); > } > @@ -447,6 +451,8 @@ > result = file_cmd(ec, EFSD_CMD_COPY, num_files, files, ops->num_used, > ops->ops); > else > result = file_cmd(ec, EFSD_CMD_COPY, num_files, files, 0, NULL); > + > + FREE(ops); > > D_RETURN_(result); > } > @@ -479,6 +485,8 @@ > result = file_cmd(ec, EFSD_CMD_LISTDIR, 1, &dirname, ops->num_used, > ops->ops); > else > result = file_cmd(ec, EFSD_CMD_LISTDIR, 1, &dirname, 0, NULL); > + > + FREE(ops); > > D_RETURN_(result); > } > @@ -800,6 +808,8 @@ > else > result = file_cmd(ec, type, 1, &filename, 0, NULL); > > + FREE(ops); > + > D_RETURN_(result); > } > > > > > _______________________________________________ > Enlightenment-cvs mailing list > Enl...@li... > http://lists.sourceforge.net/lists/listinfo/enlightenment-cvs -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +61 (0)408 363 984 Work Phone: +61 (02) 9386 9362 |
From: Christian K. <kre...@in...> - 2001-08-17 01:17:04
|
"Carsten Haitzler (The Rasterman)" wrote: > > On Thu, 16 Aug 2001 17:47:45 -0700 enl...@li... > babbled profusely: > > > Log Message: > > Oooh the options do get cleaned up, but not their container :) > > Raster, does this fix it? > > yup. fixed :) tnx! :) ____ , / oo \ =D _| \__/ |_/ / \____/ @, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: <ra...@ra...> - 2001-10-01 05:44:41
|
On Sun, 30 Sep 2001 11:35:07 -0700 enl...@li... babbled profusely: > Here's libefsd command queue handling. When Efsd cannot send all commands as > necessary, > commands are now queued on the client side. The queueing is transparent to the > client, > i.e. when commands need to be queued, Efsd calls still return the command ID, > as usual. You can > check whether commands are queued at any time using efsd_commands_pending(), > and > efsd_flush() to flush the queue. This call will *not* block. It tries to write > as many queued > commands as possible, but always returns. The idea here is to never see a > client app hanging in > case Efsd screws > up. efsd_flush() returns a value > 0 when the queue could be flushed > completely. > > The queue is reduced as much as possible with every Efsd command sent. > > Raster, as far as I can see the correct way to handle this would be to modify > Ecore to also > allow event callbacks to be executed when an fd becomes ready to be *written > to*. When > efsd_commands_pending() tells you that commands are queued, add an fd event > handler when the > Efsd connection fd becomes writeable, and then call efsd_flush() in the > handler. When > efsd_flush()s return value indicates more commands are in the queue, keep > setting the handler. > > I have not modified anything in e17 yet. Here's what I currently see when I > set all the > metadata on a large directory: for a while all works well, and depending on > the timing of > things, the queue first builds up and then gets eliminated or keeps increasing > until all > metadata commands are issued. Some are still hanging in the queue at this > time, because there's > no logic yet to smartly flush the queue. You'll then notice that the queue is > worked up as soon > as you issue any other efsd commands, e.g. when opening another view. yup. i've changed E so it uses that all now.. it should be happy and handle it nicely. the problem is efsd segv's.... butonly if u have threads enabled, so i'm finding it hard to track down... (just open up /dev in e17) also i optimised efsd's meta data handling stuff.. much better now.. at least in my tests.. as isaid in my commit log - the mime type stuff could be faster too :) > Btw I don't see why it's necessary to set all that x/y metadata to 9999999 > when a view is first > opened? I think it would make more sense to make the icon layout smarter and > use default > layouts with overriding x/y coordinates when they're available. actually that was there to avoid an event storm cause by default themouse x/y is at 0,0 until it gets an event... (ie mouse enter/move) and since its async it coudl be a little while till it gets to it.. so moving the ciosn other than being @ 0,0 movies them away form generating a bit of an event storm :o) cheap trick... but works :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... Unemployed Bum ra...@de... Mobile Phone: +61 (0)408 363 984 Home Phone: 02 9386 9362 |
From: Christian K. <kre...@in...> - 2001-10-01 16:56:24
|
ra...@ra... wrote: > > yup. i've changed E so it uses that all now.. it should be happy and handle it > nicely. the problem is efsd segv's.... butonly if u have threads enabled, so i'm > finding it hard to track down... (just open up /dev in e17) I know, but I've seen weirder things too. For example, when I open a large dir (/usr/bin, /dev etc) I see an infinite loop of files being handled, i.e. I see all files in the dir rushing through my shell, and then things start right from the beginning. I aborted efsd and e17 when the write queue had grown to some 5000 unsent items :) Thought I'd commit anyway for now, as my time for E is fairly limited right now. Do you have any idea what might cause the loop issue? Do you see that too? The threads thing is a good hint though. > also i optimised efsd's meta data handling stuff.. much better now.. at least in > my tests.. as isaid in my commit log - the mime type stuff could be faster too > :) Well, putting all the data into one db is fine as long as things still work as before. Do your patches handle the cases of moving metadata in and out of those db's as well, e.g. when moving files around? Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2001-10-01 19:05:35
|
Christian Kreibich wrote: > > > also i optimised efsd's meta data handling stuff.. much better now.. at least in > > my tests.. as isaid in my commit log - the mime type stuff could be faster too > > :) > > Well, putting all the data into one db is fine as long as things still > work as before. Do your patches handle the cases of moving metadata in > and out of those db's as well, e.g. when moving files around? Another thing -- the per-file metadata db files took care of the case when multiple users had write access to a dir for setting metadata, because the uid was part of the hash. So I suggest we now use one metadata db file per user? -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2001-10-01 17:51:12
|
Christian Kreibich wrote: > > right now. Do you have any idea what might cause the loop issue? Do you > see that too? Ah, okay. That was easy. Efsd dies and e17 restarts the command. Doh :) I'll chase the segv now. Stay tuned for more live coverage on the topic here on this station. Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: <ra...@ra...> - 2001-10-02 03:51:56
|
On Mon, 01 Oct 2001 19:51:03 +0200 Christian Kreibich <kre...@in...> babbled profusely: > Christian Kreibich wrote: > > > > right now. Do you have any idea what might cause the loop issue? Do you > > see that too? > > Ah, okay. That was easy. Efsd dies and e17 restarts the command. Doh :) > I'll chase the segv now. Stay tuned for more live coverage on the topic > here on this station. yeah. e17 is very insistant on starting up efsd again if it dies on it... tho it does back off if it cant get to talk to efsd again for a biyt.. eventually it just sits there and every 10 secs tries to start efsd and connect. maybe i shoudl put in a life meter too that will figure if efsd has only been around for like 5 or 10 secs... if it keeps dieing every 5 secs it'l give up too... tho this solves the problem of stability that shoudl be fixed in the end anwyay... the restart stuff is there incase users go killing off processes "what is this process - bah! kill it- dont need it. i don't use it!... oops!" :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... Unemployed Bum ra...@de... Mobile Phone: +61 (0)408 363 984 Home Phone: 02 9386 9362 |
From: <ra...@ra...> - 2001-10-02 03:51:56
|
On Mon, 01 Oct 2001 11:50:14 -0700 enl...@li... babbled profusely: > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > > Modified Files: > efsd_event_queue.c efsd_main.c > > > Log Message: > I think this fixes the segfault. Raster? > > Btw, in e17, is the new fs_idle event handler actually hooked in? oooh geez.. it isn't.. oops :) heheheheheh -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... Unemployed Bum ra...@de... Mobile Phone: +61 (0)408 363 984 Home Phone: 02 9386 9362 |
From: Andrew S. <an...@ne...> - 2001-10-24 02:42:33
|
> Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/doc > > > Modified Files: > Makefile.am > > > Log Message: > Oops. > > =================================================================== > RCS file: /cvsroot/enlightenment/e17/apps/efsd/doc/Makefile.am,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -3 -r1.7 -r1.8 > --- Makefile.am 2001/10/23 21:42:08 1.7 > +++ Makefile.am 2001/10/23 22:33:18 1.8 > @@ -35,7 +35,7 @@ > - cd figures && cp -f *.png ../$(FULLNAME)/figures > - cd figures && cp -f *.jpg ../$(FULLNAME)/figures > cp -f stylesheet.css $(FULLNAME)/stylesheet.css > - tar cfvz --exclude=CVS $(FULLNAME).tar.gz $(FULLNAME) > + tar cfvz $(FULLNAME).tar.gz $(FULLNAME) > I don't think you should rely on tar being this portable. On some systems you'd need to call gtar or gnutar. You might be better off finding appropriate programs and doing: $(TAR) cvf $(FULLNAME).tar && $(GZIP) $(FULLNAME).tar (Not sure if the '&&' is valid in a Makefile but you get the idea.) Or you could just add GNU tar to the list of prerequisites. =) Andrew. -- Andrew Shugg <an...@ne...> http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." |
From: Michael J. <e-...@ka...> - 2001-10-24 02:53:03
|
On Wednesday, 24 October 2001, at 10:42:03 (+0800), Andrew Shugg wrote: > I don't think you should rely on tar being this portable. On some > systems you'd need to call gtar or gnutar. You might be better off > finding appropriate programs and doing: > > $(TAR) cvf $(FULLNAME).tar && $(GZIP) $(FULLNAME).tar Good call. Bad cK. > (Not sure if the '&&' is valid in a Makefile but you get the idea.) It is. :) > Or you could just add GNU tar to the list of prerequisites. =) Bad idea, mr_shugg. Don't make me come over there. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n+1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "I've looked for you all of my life. Now that I've found you, we will never say goodbye. I can't stop this feeling; there's nothing I can do 'cause I see everything when I look at you." -- Firehouse, "When I Look into Your Eyes" |
From: Andrew S. <an...@ne...> - 2001-10-24 04:00:02
|
Quoth Michael Jennings: [...] > > Or you could just add GNU tar to the list of prerequisites. =) > > Bad idea, mr_shugg. Don't make me come over there. :) > > Michael It's a long swim; I'm betting you can't be bothered. =P Andrew. -- Andrew Shugg <an...@ne...> http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh." |
From: Christian K. <kre...@in...> - 2001-10-24 08:02:50
|
Michael Jennings wrote: > > On Wednesday, 24 October 2001, at 10:42:03 (+0800), > Andrew Shugg wrote: > > > I don't think you should rely on tar being this portable. On some > > systems you'd need to call gtar or gnutar. You might be better off > > finding appropriate programs and doing: > > > > $(TAR) cvf $(FULLNAME).tar && $(GZIP) $(FULLNAME).tar > > Good call. Bad cK. Bahbahbah yeah I know. We've had those issues before, and I've been on Solaris for a while :) I wonder how many people will build tarballs from efsd doco -- I'll fix it later this week, last night I just wanted this to work on my machine. > > (Not sure if the '&&' is valid in a Makefile but you get the idea.) > > It is. :) > > > Or you could just add GNU tar to the list of prerequisites. =) > > Bad idea, mr_shugg. Don't make me come over there. :) :o) Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2001-11-16 16:57:26
|
enl...@li... wrote: > > Enlightenment CVS committal > > Author : cpk > Project : e17 > Module : apps/efsd > > Dir : e17/apps/efsd/efsd > > Modified Files: > efsd_commands.c efsd_debug.h efsd_filetype.c efsd_fs.c > efsd_lock.c efsd_macros.h efsd_main.c efsd_meta.c efsd_meta.h > efsd_misc.c efsd_misc.h efsd_monitor.c efsd_statcache.c > libefsd.c libefsd.h > > Log Message: > I've fixed the metadata handling after Raster's changes from a while > ago. All metadata is now stored in a single file (one file per user). > This was quite a bit of work, so there may be bugs left. I've also > fixed a few smaller bugs along the way and added doco comments. Before you ask -- there's still metadata spread out over the filesystem, what I meant was that in each metadata directory, there's now only one metadata file per user. Metadata that can't be written locally in a directory goes into ~/.e/efsd/efsd_meta.db. -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@ac...> - 2001-02-07 19:56:29
|
Andrew Shugg wrote: > > > Author : cpk > > Project : e17 > > Module : apps/efsd > [...] > > - /* We're whimp's here and just exit. */ > > + /* We're whimps here and just exit. */ > > Actually, there's no 'h' in wimps. =) Ah, I was afraid somebody would pick up on that. Those pesky commit messages. Sometimes people tend to forget that I'm not a native speaker :) Cheers, -- Christian. ________________________________________________________________________ International Computer Science Institute, ACIRI Group mailto:kre...@ac... |
From: Hall S. <hal...@mi...> - 2001-02-07 20:24:19
|
> Andrew Shugg wrote: > > > > > Author : cpk > > > Project : e17 > > > Module : apps/efsd > > [...] > > > - /* We're whimp's here and just exit. */ > > > + /* We're whimps here and just exit. */ > > > > Actually, there's no 'h' in wimps. =) > > Ah, I was afraid somebody would pick up on that. > Those pesky commit messages. Sometimes people > tend to forget that I'm not a native speaker > :) Don't be ashamed. Many people who speak and write English natively would have wrote "/* Were wimp's here and just exit. */" ;-) Regards Hall |