Muahahahahaha

M

mimus

Guest
My nifty little version of the bash command cp, cpultrad, just copied

18,188 files totalling 46,382,978 bytes from one directory to another.

So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on

this here system to a mere 131,072 bytes allowed for bash command

arguments (and a little for environment).

("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead

read-and-write copy for each regular file in the origin-directory in

succession. I suspect a system call to cp for each file in succession

might be a little faster, even with those repeated system-calls, since

again I suspect that a copy op doesn't necessarily involve a drop-dead

actual copying with this here filesystem, just some linking, and I may try

that version next-- "cpultra"-- just to see.)

((And then-- and then-- rmultra, to among other things kill all those

goddam thumbnails in the goddam Gnome thumbnail-server's goddam

thumbnail-directory-- talk about slow, after over two years of

accumulation, and rm just chokes on it-- ARG_MAX again.))

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

When a system is set up to accomplish some goal, a

new entity has come into being--the system itself.

Now the system itself has to be dealt with.

< _Systemantics_

 
M

mimus

Guest
On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


> My nifty little version of the bash command cp, cpultrad, just copied


> 18,188 files totalling 46,382,978 bytes from one directory to another.


>


> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


> this here system to a mere 131,072 bytes allowed for bash command


> arguments (and a little for environment).


>


> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


> read-and-write copy for each regular file in the origin-directory in


> succession. I suspect a system call to cp for each file in succession


> might be a little faster, even with those repeated system-calls, since


> again I suspect that a copy op doesn't necessarily involve a drop-dead


> actual copying with this here filesystem, just some linking, and I may try


> that version next-- "cpultra"-- just to see.)


>


> ((And then-- and then-- rmultra, to among other things kill all those


> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


> thumbnail-directory-- talk about slow, after over two years of


> accumulation, and rm just chokes on it-- ARG_MAX again.))

rmultra revealed after doing its evil work that I had had 57,842

thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454

bytes.

A WHOLE GIGABYTE OF THUMBNAILS.

On my 40 GB HD.

I don't think much of the Gnome thumbnail-manager, I must say.

But they're all gone now.

Incidentally, that comes out to about 20K each, which sounds awfully big

for a thumbnail, but I just ran up a bunch again and checked the directory

and that's about what they run (PNGs). Weird. They must not be

compressed at all.

Now, to sort through my Pan messages cache, filtering them to their

respective directories, in preparation for emptying it.

Lala la lala.

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

"You are either insane or a fool."

"I am a sanitary inspector."

< _Maske: Thaery_

 
D

david hillstrom

Guest
On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>

wrote:


>On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>


>> My nifty little version of the bash command cp, cpultrad, just copied


>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>


>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>> this here system to a mere 131,072 bytes allowed for bash command


>> arguments (and a little for environment).


>>


>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>> read-and-write copy for each regular file in the origin-directory in


>> succession. I suspect a system call to cp for each file in succession


>> might be a little faster, even with those repeated system-calls, since


>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>> actual copying with this here filesystem, just some linking, and I may try


>> that version next-- "cpultra"-- just to see.)


>>


>> ((And then-- and then-- rmultra, to among other things kill all those


>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>> thumbnail-directory-- talk about slow, after over two years of


>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>


>rmultra revealed after doing its evil work that I had had 57,842


>thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>bytes.


>


>A WHOLE GIGABYTE OF THUMBNAILS.


>


>On my 40 GB HD.


>


>I don't think much of the Gnome thumbnail-manager, I must say.


>


>But they're all gone now.


>


>Incidentally, that comes out to about 20K each, which sounds awfully big


>for a thumbnail, but I just ran up a bunch again and checked the directory


>and that's about what they run (PNGs). Weird. They must not be


>compressed at all.


>


>Now, to sort through my Pan messages cache, filtering them to their


>respective directories, in preparation for emptying it.


>


>Lala la lala.

file murderer.

--

dave hillstrom xrbj

 
M

mimus

Guest
On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


> wrote:


>


>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>


>>> My nifty little version of the bash command cp, cpultrad, just copied


>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>


>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>> this here system to a mere 131,072 bytes allowed for bash command


>>> arguments (and a little for environment).


>>>


>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>> read-and-write copy for each regular file in the origin-directory in


>>> succession. I suspect a system call to cp for each file in succession


>>> might be a little faster, even with those repeated system-calls, since


>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>> actual copying with this here filesystem, just some linking, and I may try


>>> that version next-- "cpultra"-- just to see.)


>>>


>>> ((And then-- and then-- rmultra, to among other things kill all those


>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>> thumbnail-directory-- talk about slow, after over two years of


>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>


>> rmultra revealed after doing its evil work that I had had 57,842


>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>> bytes.


>>


>> A WHOLE GIGABYTE OF THUMBNAILS.


>>


>> On my 40 GB HD.


>>


>> I don't think much of the Gnome thumbnail-manager, I must say.


>>


>> But they're all gone now.


>>


>> Incidentally, that comes out to about 20K each, which sounds awfully


>> big for a thumbnail, but I just ran up a bunch again and checked the


>> directory and that's about what they run (PNGs). Weird. They must not


>> be compressed at all.


>>


>> Now, to sort through my Pan messages cache, filtering them to their


>> respective directories, in preparation for emptying it.


>>


>> Lala la lala.


>


> file murderer.

Need to do a retirement-date on 'em, like replicants, I guess.

A cron job, eh? <mumble>

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

It's too bad she won't live.

But then again, who does?

< _Blade Runner_

 
D

david hillstrom

Guest
On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>

wrote:


>On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>


>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>> wrote:


>>


>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>


>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>


>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>> arguments (and a little for environment).


>>>>


>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>> read-and-write copy for each regular file in the origin-directory in


>>>> succession. I suspect a system call to cp for each file in succession


>>>> might be a little faster, even with those repeated system-calls, since


>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>> actual copying with this here filesystem, just some linking, and I may try


>>>> that version next-- "cpultra"-- just to see.)


>>>>


>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>> thumbnail-directory-- talk about slow, after over two years of


>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>


>>> rmultra revealed after doing its evil work that I had had 57,842


>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>> bytes.


>>>


>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>


>>> On my 40 GB HD.


>>>


>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>


>>> But they're all gone now.


>>>


>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>> directory and that's about what they run (PNGs). Weird. They must not


>>> be compressed at all.


>>>


>>> Now, to sort through my Pan messages cache, filtering them to their


>>> respective directories, in preparation for emptying it.


>>>


>>> Lala la lala.


>>


>> file murderer.


>


>Need to do a retirement-date on 'em, like replicants, I guess.


>


>A cron job, eh? <mumble>

cron jobs are your ~friend~, mimus.

--

dave hillstrom xrbj

 
M

mimus

Guest
On Tue, 09 Dec 2008 21:54:48 -0500, david hillstrom wrote:


> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


> wrote:


>


>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>


>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>> wrote:


>>>


>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>


>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>


>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>> arguments (and a little for environment).


>>>>>


>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>> succession. I suspect a system call to cp for each file in succession


>>>>> might be a little faster, even with those repeated system-calls, since


>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>> that version next-- "cpultra"-- just to see.)

I think I'll rename it "cpud".


>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>


>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>> bytes.


>>>>


>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>


>>>> On my 40 GB HD.


>>>>


>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>


>>>> But they're all gone now.


>>>>


>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>> be compressed at all.


>>>>


>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>> respective directories, in preparation for emptying it.


>>>>


>>>> Lala la lala.


>>>


>>> file murderer.


>>


>> Need to do a retirement-date on 'em, like replicants, I guess.


>>


>> A cron job, eh? <mumble>


>


> cron jobs are your ~friend~, mimus.

<whine:>

System-administration never ends.

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

Given a manifold M with a submanifold N, N can be knotted in M

if there exists an embedding of N in M which is not isotopic to N.

Traditional knots form the case where N = S1 and M = S3.

< Deep wisdom from on high (Wikipedia)

 
A

Aratzio

Guest
On Tue, 09 Dec 2008 21:54:48 -0500, in the land of

alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>

got double secret probation for writing:


>On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>wrote:


>


>>On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>


>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>> wrote:


>>>


>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>


>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>


>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>> arguments (and a little for environment).


>>>>>


>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>> succession. I suspect a system call to cp for each file in succession


>>>>> might be a little faster, even with those repeated system-calls, since


>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>> that version next-- "cpultra"-- just to see.)


>>>>>


>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>


>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>> bytes.


>>>>


>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>


>>>> On my 40 GB HD.


>>>>


>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>


>>>> But they're all gone now.


>>>>


>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>> be compressed at all.


>>>>


>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>> respective directories, in preparation for emptying it.


>>>>


>>>> Lala la lala.


>>>


>>> file murderer.


>>


>>Need to do a retirement-date on 'em, like replicants, I guess.


>>


>>A cron job, eh? <mumble>


>


>cron jobs are your ~friend~, mimus.

cron jobs are the oldest root hack in unix.

 
M

mimus

Guest
On Wed, 10 Dec 2008 15:38:46 -0800, Aratzio wrote:


> On Tue, 09 Dec 2008 21:54:48 -0500, in the land of


> alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>


> got double secret probation for writing:


>


>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>> wrote:


>>


>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>


>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>> wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>


>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>


>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>> arguments (and a little for environment).


>>>>>>


>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>


>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>


>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>> bytes.


>>>>>


>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>


>>>>> On my 40 GB HD.


>>>>>


>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>


>>>>> But they're all gone now.


>>>>>


>>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>>> be compressed at all.


>>>>>


>>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>>> respective directories, in preparation for emptying it.


>>>>>


>>>>> Lala la lala.


>>>>


>>>> file murderer.


>>>


>>> Need to do a retirement-date on 'em, like replicants, I guess.


>>>


>>> A cron job, eh? <mumble>


>>


>> cron jobs are your ~friend~, mimus.


>


> cron jobs are the oldest root hack in unix.

ITYM "cron jobs are _everybody's_ friend."

OK, here's another prob:

I deleted, using the remove() function from /usr/include/stdio.h in my

little C program rmultra, all those thumbnails, yet the "." directory-file

for that directory, "~/.thumbnails/normal", still shows at 2.5 MB.

I've noticed this with other directories, notably the .Trash directory

once emptied and also the Trash or Garbage or Delete directories used by

mail-clients.

Is this as it seems some sort of slowly-building ext2 filesystem bloat, or

wot?

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

When a system is set up to accomplish some goal, a

new entity has come into being--the system itself.

Now the system itself has to be dealt with.

< _Systemantics_

 
A

Aratzio

Guest
On Wed, 10 Dec 2008 19:04:35 -0500, in the land of

alt.alien.vampire.flonk.flonk.flonk, mimus <tinmimus99@hotmail.com>

got double secret probation for writing:


>On Wed, 10 Dec 2008 15:38:46 -0800, Aratzio wrote:


>


>> On Tue, 09 Dec 2008 21:54:48 -0500, in the land of


>> alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>


>> got double secret probation for writing:


>>


>>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>>> wrote:


>>>


>>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>>> wrote:


>>>>>


>>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>>


>>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>>


>>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>>> arguments (and a little for environment).


>>>>>>>


>>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>>


>>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>>


>>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>>> bytes.


>>>>>>


>>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>>


>>>>>> On my 40 GB HD.


>>>>>>


>>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>>


>>>>>> But they're all gone now.


>>>>>>


>>>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>>>> be compressed at all.


>>>>>>


>>>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>>>> respective directories, in preparation for emptying it.


>>>>>>


>>>>>> Lala la lala.


>>>>>


>>>>> file murderer.


>>>>


>>>> Need to do a retirement-date on 'em, like replicants, I guess.


>>>>


>>>> A cron job, eh? <mumble>


>>>


>>> cron jobs are your ~friend~, mimus.


>>


>> cron jobs are the oldest root hack in unix.


>


>ITYM "cron jobs are _everybody's_ friend."


>


>OK, here's another prob:


>


>I deleted, using the remove() function from /usr/include/stdio.h in my


>little C program rmultra, all those thumbnails, yet the "." directory-file


>for that directory, "~/.thumbnails/normal", still shows at 2.5 MB.


>


>I've noticed this with other directories, notably the .Trash directory


>once emptied and also the Trash or Garbage or Delete directories used by


>mail-clients.


>


>Is this as it seems some sort of slowly-building ext2 filesystem bloat, or


>wot?

not releasing i-nodes?

 
M

mimus

Guest
On Wed, 10 Dec 2008 16:21:52 -0800, Aratzio wrote:


> On Wed, 10 Dec 2008 19:04:35 -0500, in the land of


> alt.alien.vampire.flonk.flonk.flonk, mimus <tinmimus99@hotmail.com>


> got double secret probation for writing:


>


>> On Wed, 10 Dec 2008 15:38:46 -0800, Aratzio wrote:


>>


>>> On Tue, 09 Dec 2008 21:54:48 -0500, in the land of


>>> alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>


>>> got double secret probation for writing:


>>>


>>>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>>>> wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>>>


>>>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>>>> wrote:


>>>>>>


>>>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>>>


>>>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>>>


>>>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>>>> arguments (and a little for environment).


>>>>>>>>


>>>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>>>


>>>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>>>


>>>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>>>> bytes.


>>>>>>>


>>>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>>>


>>>>>>> On my 40 GB HD.


>>>>>>>


>>>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>>>


>>>>>>> But they're all gone now.


>>>>>>>


>>>>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>>>>> be compressed at all.


>>>>>>>


>>>>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>>>>> respective directories, in preparation for emptying it.


>>>>>>>


>>>>>>> Lala la lala.


>>>>>>


>>>>>> file murderer.


>>>>>


>>>>> Need to do a retirement-date on 'em, like replicants, I guess.


>>>>>


>>>>> A cron job, eh? <mumble>


>>>>


>>>> cron jobs are your ~friend~, mimus.


>>>


>>> cron jobs are the oldest root hack in unix.


>>


>> ITYM "cron jobs are _everybody's_ friend."


>>


>> OK, here's another prob:


>>


>> I deleted, using the remove() function from /usr/include/stdio.h in my


>> little C program rmultra, all those thumbnails, yet the "."


>> directory-file for that directory, "~/.thumbnails/normal", still shows


>> at 2.5 MB.


>>


>> I've noticed this with other directories, notably the .Trash directory


>> once emptied and also the Trash or Garbage or Delete directories used


>> by mail-clients.


>>


>> Is this as it seems some sort of slowly-building ext2 filesystem bloat,


>> or wot?


>


> not releasing i-nodes?

FIIK, although that's an even more alarming possibility--thanks!

Actually, after looking around on the Web, it looks like ext2 never

removes file-entries from directories, even after deleting the files, so

you can get major bloat in directories that have at least at times large

numbers of files (I guess it just writes new file-entries into the deleted

ones on a first-find first-write basis).

And after pondering the matter a bit, it looks to me like the only way to

fix major directory-file bloat-- on the order of megabytes-- is to rmdir

the directory and then re-mkdir it. (If it's not empty, then I guess

you'd have to make a new directory, mv the live files to it, and then

rmdir the old, with the appropriate directory-name finagling.)

Workarounds!

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

You want a job and a lizard to ride?

< _The Einstein Intersection_

 
M

mimus

Guest
On Wed, 10 Dec 2008 21:35:12 -0500, mimus wrote:


> On Wed, 10 Dec 2008 16:21:52 -0800, Aratzio wrote:


>


>> On Wed, 10 Dec 2008 19:04:35 -0500, in the land of


>> alt.alien.vampire.flonk.flonk.flonk, mimus <tinmimus99@hotmail.com>


>> got double secret probation for writing:


>>


>>> On Wed, 10 Dec 2008 15:38:46 -0800, Aratzio wrote:


>>>


>>>> On Tue, 09 Dec 2008 21:54:48 -0500, in the land of


>>>> alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>


>>>> got double secret probation for writing:


>>>>


>>>>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>>>>> wrote:


>>>>>


>>>>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>>>>


>>>>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>>>>> wrote:


>>>>>>>


>>>>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>>>>


>>>>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>>>>


>>>>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>>>>> arguments (and a little for environment).


>>>>>>>>>


>>>>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>>>>


>>>>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>>>>


>>>>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>>>>> bytes.


>>>>>>>>


>>>>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>>>>


>>>>>>>> On my 40 GB HD.


>>>>>>>>


>>>>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>>>>


>>>>>>>> But they're all gone now.


>>>>>>>>


>>>>>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>>>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>>>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>>>>>> be compressed at all.


>>>>>>>>


>>>>>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>>>>>> respective directories, in preparation for emptying it.


>>>>>>>>


>>>>>>>> Lala la lala.


>>>>>>>


>>>>>>> file murderer.


>>>>>>


>>>>>> Need to do a retirement-date on 'em, like replicants, I guess.


>>>>>>


>>>>>> A cron job, eh? <mumble>


>>>>>


>>>>> cron jobs are your ~friend~, mimus.


>>>>


>>>> cron jobs are the oldest root hack in unix.


>>>


>>> ITYM "cron jobs are _everybody's_ friend."


>>>


>>> OK, here's another prob:


>>>


>>> I deleted, using the remove() function from /usr/include/stdio.h in my


>>> little C program rmultra, all those thumbnails, yet the "."


>>> directory-file for that directory, "~/.thumbnails/normal", still shows


>>> at 2.5 MB.


>>>


>>> I've noticed this with other directories, notably the .Trash directory


>>> once emptied and also the Trash or Garbage or Delete directories used


>>> by mail-clients.


>>>


>>> Is this as it seems some sort of slowly-building ext2 filesystem bloat,


>>> or wot?


>>


>> not releasing i-nodes?


>


> FIIK, although that's an even more alarming possibility--thanks!


>


> Actually, after looking around on the Web, it looks like ext2 never


> removes file-entries from directories, even after deleting the files, so


> you can get major bloat in directories that have at least at times large


> numbers of files (I guess it just writes new file-entries into the deleted


> ones on a first-find first-write basis).


>


> And after pondering the matter a bit, it looks to me like the only way to


> fix major directory-file bloat-- on the order of megabytes-- is to rmdir


> the directory and then re-mkdir it. (If it's not empty, then I guess


> you'd have to make a new directory, mv the live files to it, and then


> rmdir the old, with the appropriate directory-name finagling.)


>


> Workarounds!

Ooh, yeah, just freed up 2.5 MB - 4 K . . . .

Obviously we need a hunter program to work through the filesystem

recursively and do this any time it would save over, say, half a meg

(default, with option to reset).

<brood>

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

When a system is set up to accomplish some goal, a

new entity has come into being--the system itself.

Now the system itself has to be dealt with.

< _Systemantics_

 
A

ah

Guest
mimus wrote:


> On Tue, 09 Dec 2008 21:54:48 -0500, david hillstrom wrote:


>


>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>> wrote:


>>


>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>


>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>> wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>


>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>


>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>> arguments (and a little for environment).


>>>>>>


>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>> that version next-- "cpultra"-- just to see.)


>


> I think I'll rename it "cpud".

Uh, 'pud's not a big winner, marketing-wise.


>


>>>>>> [...]

--

ah

 
A

ah

Guest
Aratzio wrote:


> On Wed, 10 Dec 2008 19:04:35 -0500, in the land of


> alt.alien.vampire.flonk.flonk.flonk, mimus <tinmimus99@hotmail.com>


> got double secret probation for writing:


>


>>On Wed, 10 Dec 2008 15:38:46 -0800, Aratzio wrote:


>>


>>> On Tue, 09 Dec 2008 21:54:48 -0500, in the land of


>>> alt.alien.vampire.flonk.flonk.flonk, david hillstrom <dave@meow.org>


>>> got double secret probation for writing:


>>>


>>>> On Tue, 09 Dec 2008 13:54:23 -0500, mimus <tinmimus99@hotmail.com>


>>>> wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom wrote:


>>>>>


>>>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>>>> wrote:


>>>>>>


>>>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>>>


>>>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>>>


>>>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>>>> arguments (and a little for environment).


>>>>>>>>


>>>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>>>


>>>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>>>


>>>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>>>> bytes.


>>>>>>>


>>>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>>>


>>>>>>> On my 40 GB HD.


>>>>>>>


>>>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>>>


>>>>>>> But they're all gone now.


>>>>>>>


>>>>>>> Incidentally, that comes out to about 20K each, which sounds awfully


>>>>>>> big for a thumbnail, but I just ran up a bunch again and checked the


>>>>>>> directory and that's about what they run (PNGs). Weird. They must not


>>>>>>> be compressed at all.


>>>>>>>


>>>>>>> Now, to sort through my Pan messages cache, filtering them to their


>>>>>>> respective directories, in preparation for emptying it.


>>>>>>>


>>>>>>> Lala la lala.


>>>>>>


>>>>>> file murderer.


>>>>>


>>>>> Need to do a retirement-date on 'em, like replicants, I guess.


>>>>>


>>>>> A cron job, eh? <mumble>


>>>>


>>>> cron jobs are your ~friend~, mimus.


>>>


>>> cron jobs are the oldest root hack in unix.


>>


>>ITYM "cron jobs are _everybody's_ friend."


>>


>>OK, here's another prob:


>>


>>I deleted, using the remove() function from /usr/include/stdio.h in my


>>little C program rmultra, all those thumbnails, yet the "." directory-file


>>for that directory, "~/.thumbnails/normal", still shows at 2.5 MB.


>>


>>I've noticed this with other directories, notably the .Trash directory


>>once emptied and also the Trash or Garbage or Delete directories used by


>>mail-clients.


>>


>>Is this as it seems some sort of slowly-building ext2 filesystem bloat, or


>>wot?


>


> not releasing i-nodes?

"Release the i-nodes, Onan!"

--

ah

 
M

metro-golden-meower

Guest
On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>

wrote:


>On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>


>> My nifty little version of the bash command cp, cpultrad, just copied


>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>


>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>> this here system to a mere 131,072 bytes allowed for bash command


>> arguments (and a little for environment).


>>


>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>> read-and-write copy for each regular file in the origin-directory in


>> succession. I suspect a system call to cp for each file in succession


>> might be a little faster, even with those repeated system-calls, since


>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>> actual copying with this here filesystem, just some linking, and I may try


>> that version next-- "cpultra"-- just to see.)


>>


>> ((And then-- and then-- rmultra, to among other things kill all those


>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>> thumbnail-directory-- talk about slow, after over two years of


>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>


>rmultra revealed after doing its evil work that I had had 57,842


>thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>bytes.


>


>A WHOLE GIGABYTE OF THUMBNAILS.


>


>On my 40 GB HD.


>


>I don't think much of the Gnome thumbnail-manager, I must say.


>


>But they're all gone now.

deleted or you backed up your girlys playing tennis picks for later

viewing?


>Incidentally, that comes out to about 20K each, which sounds awfully big


>for a thumbnail, but I just ran up a bunch again and checked the directory


>and that's about what they run (PNGs). Weird. They must not be


>compressed at all.


>


>Now, to sort through my Pan messages cache, filtering them to their


>respective directories, in preparation for emptying it.


>


>Lala la lala.

 
M

metro-golden-meower

Guest
On Tue, 09 Dec 2008 12:20:49 -0500, david hillstrom <dave@meow.org>

wrote:


>On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>wrote:


>


>>On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>


>>> My nifty little version of the bash command cp, cpultrad, just copied


>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>


>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>> this here system to a mere 131,072 bytes allowed for bash command


>>> arguments (and a little for environment).


>>>


>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>> read-and-write copy for each regular file in the origin-directory in


>>> succession. I suspect a system call to cp for each file in succession


>>> might be a little faster, even with those repeated system-calls, since


>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>> actual copying with this here filesystem, just some linking, and I may try


>>> that version next-- "cpultra"-- just to see.)


>>>


>>> ((And then-- and then-- rmultra, to among other things kill all those


>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>> thumbnail-directory-- talk about slow, after over two years of


>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>


>>rmultra revealed after doing its evil work that I had had 57,842


>>thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>bytes.


>>


>>A WHOLE GIGABYTE OF THUMBNAILS.


>>


>>On my 40 GB HD.


>>


>>I don't think much of the Gnome thumbnail-manager, I must say.


>>


>>But they're all gone now.


>>


>>Incidentally, that comes out to about 20K each, which sounds awfully big


>>for a thumbnail, but I just ran up a bunch again and checked the directory


>>and that's about what they run (PNGs). Weird. They must not be


>>compressed at all.


>>


>>Now, to sort through my Pan messages cache, filtering them to their


>>respective directories, in preparation for emptying it.


>>


>>Lala la lala.


>


>file murderer.

he'll have ghost files kicking **** like in the matrix.

 
M

mimus

Guest
On Fri, 26 Dec 2008 17:32:27 +0000, metro-golden-meower wrote:


> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


> wrote:


>


>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>


>>> My nifty little version of the bash command cp, cpultrad, just copied


>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>


>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>> this here system to a mere 131,072 bytes allowed for bash command


>>> arguments (and a little for environment).


>>>


>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>> read-and-write copy for each regular file in the origin-directory in


>>> succession. I suspect a system call to cp for each file in succession


>>> might be a little faster, even with those repeated system-calls, since


>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>> actual copying with this here filesystem, just some linking, and I may try


>>> that version next-- "cpultra"-- just to see.)


>>>


>>> ((And then-- and then-- rmultra, to among other things kill all those


>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>> thumbnail-directory-- talk about slow, after over two years of


>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>


>> rmultra revealed after doing its evil work that I had had 57,842


>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>> bytes.


>>


>> A WHOLE GIGABYTE OF THUMBNAILS.


>>


>> On my 40 GB HD.


>>


>> I don't think much of the Gnome thumbnail-manager, I must say.


>>


>> But they're all gone now.


>


> deleted or you backed up your girlys playing tennis picks for later


> viewing?

Gone with the wind. Unless someone can use a track-'n'-sector reader to

fish some of 'em back out.

BTW, Nadia Petrova, a rather witchy-lookin' Russian tennis-player,

who usually hangs around Numbah Ten in the world, just contracted viral

meningitis in Argentina where she'd gone to train, and is hospitalized

there, and there's hardly a dam' thing about it on the Web.

Both the illness and the lack of concern on the part of the tennis-world--

and even the Russian press! not that Pravda's English-language website

doesn't read like a Russian FauxNews (and that's probably toned down

for the international audience)-- suck.

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

In the old time, there was love in the forest.

< _Where Is the Bird of Fire?_

 
M

metro-golden-meower

Guest
On Fri, 26 Dec 2008 17:03:29 -0500, mimus <tinmimus99@hotmail.com>

wrote:


>On Fri, 26 Dec 2008 17:32:27 +0000, metro-golden-meower wrote:


>


>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>> wrote:


>>


>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>


>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>


>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>> arguments (and a little for environment).


>>>>


>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>> read-and-write copy for each regular file in the origin-directory in


>>>> succession. I suspect a system call to cp for each file in succession


>>>> might be a little faster, even with those repeated system-calls, since


>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>> actual copying with this here filesystem, just some linking, and I may try


>>>> that version next-- "cpultra"-- just to see.)


>>>>


>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>> thumbnail-directory-- talk about slow, after over two years of


>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>


>>> rmultra revealed after doing its evil work that I had had 57,842


>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>> bytes.


>>>


>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>


>>> On my 40 GB HD.


>>>


>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>


>>> But they're all gone now.


>>


>> deleted or you backed up your girlys playing tennis picks for later


>> viewing?


>


>Gone with the wind. Unless someone can use a track-'n'-sector reader to


>fish some of 'em back out.

apparently there are now tools available to get back deleted files on

a nix system!


>BTW, Nadia Petrova, a rather witchy-lookin' Russian tennis-player,


>who usually hangs around Numbah Ten in the world, just contracted viral


>meningitis in Argentina where she'd gone to train, and is hospitalized


>there, and there's hardly a dam' thing about it on the Web.

i just cannot get into this tennis thing. even if there are some cute

girlys playing it.


>Both the illness and the lack of concern on the part of the tennis-world--


>and even the Russian press! not that Pravda's English-language website


>doesn't read like a Russian FauxNews (and that's probably toned down


>for the international audience)-- suck.

 
M

mimus

Guest
On Sat, 27 Dec 2008 15:46:58 +0000, metro-golden-meower wrote:


> On Fri, 26 Dec 2008 17:03:29 -0500, mimus <tinmimus99@hotmail.com>


> wrote:


>


>>On Fri, 26 Dec 2008 17:32:27 +0000, metro-golden-meower wrote:


>>


>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>> wrote:


>>>


>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>


>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>


>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>> arguments (and a little for environment).


>>>>>


>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>> succession. I suspect a system call to cp for each file in succession


>>>>> might be a little faster, even with those repeated system-calls, since


>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>> that version next-- "cpultra"-- just to see.)


>>>>>


>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>


>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>> bytes.


>>>>


>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>


>>>> On my 40 GB HD.


>>>>


>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>


>>>> But they're all gone now.


>>>


>>> deleted or you backed up your girlys playing tennis picks for later


>>> viewing?


>>


>> Gone with the wind. Unless someone can use a track-'n'-sector reader


>> to fish some of 'em back out.


>


> apparently there are now tools available to get back deleted files on a


> nix system!

Well, on ext2/3, all you do when you delete a file is alter the

directory-entry for the file, not even deleting it, so as long as the

directory-entry and the file-blocks haven't been re-used, you should be

able to un-delete it fairly easily.


>> BTW, Nadia Petrova, a rather witchy-lookin' Russian tennis-player,


>> who usually hangs around Numbah Ten in the world, just contracted viral


>> meningitis in Argentina where she'd gone to train, and is hospitalized


>> there, and there's hardly a dam' thing about it on the Web.


>


> i just cannot get into this tennis thing. even if there are some cute


> girlys playing it.

Great fun, a truly international sport, and you rapidly come to know the

top players (the ones left toward the ends of tournaments), their styles,

and how they fare against one another.

And, yes, there are definitely some babes runnin' around on the women's

side.

--

tinmimus99@hotmail.com

smeeter 11 or maybe 12

mp 10

mhm 29x13

Take a deep breath, take a walk, cool off, plot a bit, and serve again.

 
M

metro-golden-meower

Guest
On Sat, 27 Dec 2008 15:49:15 -0500, mimus <tinmimus99@hotmail.com>

wrote:


>On Sat, 27 Dec 2008 15:46:58 +0000, metro-golden-meower wrote:


>


>> On Fri, 26 Dec 2008 17:03:29 -0500, mimus <tinmimus99@hotmail.com>


>> wrote:


>>


>>>On Fri, 26 Dec 2008 17:32:27 +0000, metro-golden-meower wrote:


>>>


>>>> On Tue, 09 Dec 2008 05:45:30 -0500, mimus <tinmimus99@hotmail.com>


>>>> wrote:


>>>>


>>>>> On Tue, 09 Dec 2008 02:18:14 -0500, mimus wrote:


>>>>>


>>>>>> My nifty little version of the bash command cp, cpultrad, just copied


>>>>>> 18,188 files totalling 46,382,978 bytes from one directory to another.


>>>>>>


>>>>>> So there <spit> for Linux and its vile ARG_MAX, set (hard-compiled!) on


>>>>>> this here system to a mere 131,072 bytes allowed for bash command


>>>>>> arguments (and a little for environment).


>>>>>>


>>>>>> ("cpultrad" = "cp-ultra-drop-dead", basically; it does a drop-dead


>>>>>> read-and-write copy for each regular file in the origin-directory in


>>>>>> succession. I suspect a system call to cp for each file in succession


>>>>>> might be a little faster, even with those repeated system-calls, since


>>>>>> again I suspect that a copy op doesn't necessarily involve a drop-dead


>>>>>> actual copying with this here filesystem, just some linking, and I may try


>>>>>> that version next-- "cpultra"-- just to see.)


>>>>>>


>>>>>> ((And then-- and then-- rmultra, to among other things kill all those


>>>>>> goddam thumbnails in the goddam Gnome thumbnail-server's goddam


>>>>>> thumbnail-directory-- talk about slow, after over two years of


>>>>>> accumulation, and rm just chokes on it-- ARG_MAX again.))


>>>>>


>>>>> rmultra revealed after doing its evil work that I had had 57,842


>>>>> thumbnails in there (~/.thumbnails/normal) accounting for 1,135,738,454


>>>>> bytes.


>>>>>


>>>>> A WHOLE GIGABYTE OF THUMBNAILS.


>>>>>


>>>>> On my 40 GB HD.


>>>>>


>>>>> I don't think much of the Gnome thumbnail-manager, I must say.


>>>>>


>>>>> But they're all gone now.


>>>>


>>>> deleted or you backed up your girlys playing tennis picks for later


>>>> viewing?


>>>


>>> Gone with the wind. Unless someone can use a track-'n'-sector reader


>>> to fish some of 'em back out.


>>


>> apparently there are now tools available to get back deleted files on a


>> nix system!


>


>Well, on ext2/3, all you do when you delete a file is alter the


>directory-entry for the file, not even deleting it, so as long as the


>directory-entry and the file-blocks haven't been re-used, you should be


>able to un-delete it fairly easily.

i really should have another go at learning linux. its not like i

don't have room for it on my new terrabyte hdd or could use a 250 gig

hdd i have for it.


>>> BTW, Nadia Petrova, a rather witchy-lookin' Russian tennis-player,


>>> who usually hangs around Numbah Ten in the world, just contracted viral


>>> meningitis in Argentina where she'd gone to train, and is hospitalized


>>> there, and there's hardly a dam' thing about it on the Web.


>>


>> i just cannot get into this tennis thing. even if there are some cute


>> girlys playing it.


>


>Great fun, a truly international sport, and you rapidly come to know the


>top players (the ones left toward the ends of tournaments), their styles,


>and how they fare against one another.

i believe you. i just don't have the patience to watch it. i really do

find tennish boring. my old man used to watch it when i was a kid. i

think that's part of the reason i cannot watch it now.


>And, yes, there are definitely some babes runnin' around on the women's


>side.

i'm sure there are. but i just don't like tennis, probably in the same

way people don't like cricket which i think is a more interesting

game.

 
You must log in or register to reply here.
Top Bottom