[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

skipping bytes

Bill Cunningham

7/19/2011 9:15:00 AM

I want to take a 700MB file and skip evey 200MB, so I thought of this.

long * space=malloc(sizeof(long)*500000);

That would be good for code wouldn't it? Now how to tell where I am in the
file. I have two choices. ftell() and fseek() or use f*pos() functions.
Would anyone have any suggestions?

Bill
4 Answers

blmblm@myrealbox.com

7/19/2011 9:34:00 PM

0

In article <1abeef95-22ff-499a-b3c2-ab1a24e21c44@h25g2000prf.googlegroups.com>,
Chad <cdalten@gmail.com> wrote:
> On Jul 19, 10:27 am, blm...@myrealbox.com <blmblm.myreal...@gmail.com>
> wrote:
> > In article <4e24a90b$0$8602$bbae4...@news.suddenlink.net>,
> >
> >
> >
> >
> >
> > Bill Cunningham <nos...@nspam.invalid> wrote:
> > > John Gordon wrote:
> > > > In <4e24a281$0$1929$bbae4...@news.suddenlink.net> "Bill Cunningham"
> > > > <nos...@nspam.invalid> writes:
> >
> > > >> I want to take a 700MB file and skip evey 200MB, so I thought of
> > > >> this.
> >
> > > > You mean you want to copy the 700MB file to another file, omitting
> > > > 200MB chunks?
> >
> > > >> long * space=malloc(sizeof(long)*500000);
> >
> > > > There's no need to allocate that much space for a simple copy
> > > > operation.
> > > > You can copy, say, 8K or 16K at a time without allocating a huge
> > > > buffer.
> >
> > > I actually wanted to do something a little more difficult than just copy
> > > the file. Every 200MB I want to save in a buffer about 8 bytes of data and
> > > exchange 0x0000 for it. It doesn't have to be every 200M but it's such a
> > > large file I thought of 200MB. Not using malloc() makes things so much
> > > easier. It doesn't have to be exactly 8 bytes it could be 32. The important
> > > thing is to correctly store the data read and save it correctly so it could
> > > be put back.
> >
> > Do you have some end goal in mind, or are you doing this because it
> > somehow strikes you as an interesting or entertaining problem in its
> > own right? I can't make much sense of the above description and am
> > (mildly) curious.
> >
> > [ snip ]
> >
>
> You obviously haven't hung around this joint long enough.
>

Au contraire -- but in the past it has been a lot clearer what
Bill wanted to accomplish, even when the posted code didn't seem
very promising as a way to accomplish the stated goal.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

blmblm@myrealbox.com

7/19/2011 9:36:00 PM

0

In article <4e25d86a$0$1975$bbae4d71@news.suddenlink.net>,
Bill Cunningham <nospam@nspam.invalid> wrote:
> blmblm@myrealbox.com wrote:
> > In article <4e24a90b$0$8602$bbae4d71@news.suddenlink.net>,
> > Bill Cunningham <nospam@nspam.invalid> wrote:
> >> John Gordon wrote:
> >>> In <4e24a281$0$1929$bbae4d71@news.suddenlink.net> "Bill Cunningham"
> >>> <nospam@nspam.invalid> writes:
> >>>
> >>>> I want to take a 700MB file and skip evey 200MB, so I thought
> >>>> of this.
> >>>
> >>> You mean you want to copy the 700MB file to another file, omitting
> >>> 200MB chunks?
> >>>
> >>>> long * space=malloc(sizeof(long)*500000);
> >>>
> >>> There's no need to allocate that much space for a simple copy
> >>> operation.
> >>> You can copy, say, 8K or 16K at a time without allocating a huge
> >>> buffer.
> >>
> >> I actually wanted to do something a little more difficult than
> >> just copy the file. Every 200MB I want to save in a buffer about 8
> >> bytes of data and exchange 0x0000 for it. It doesn't have to be
> >> every 200M but it's such a large file I thought of 200MB. Not using
> >> malloc() makes things so much easier. It doesn't have to be exactly
> >> 8 bytes it could be 32. The important thing is to correctly store
> >> the data read and save it correctly so it could be put back.
> >
> > Do you have some end goal in mind, or are you doing this because it
> > somehow strikes you as an interesting or entertaining problem in its
> > own right? I can't make much sense of the above description and am
> > (mildly) curious.
>
> Please don't say "don't reinvent the wheel" it's all been done.
> Everything is a learning experience. By punching "holes" in a file you make
> it unreadable. By saving that information and reinserting it it becomes
> readable again.

Oh! Okay, well, that's not a task I'd have set myself, but this
description is *almost* enough for me to imagine what the code
might be like, and I guess I can sort of understand how it might
seem like an interesting problem. (Depending on what kind of file
it is, just replacing some of the data might or might not make it
totally unreadable. But that may not matter to you.)

One question you might ask yourself is where you're going to
save the data you overwrite and want to put back later -- will
it go in some separate file, or in some predetermined place in
the original, or what?

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

Bill Cunningham

7/20/2011 11:01:00 AM

0

blmblm@myrealbox.com wrote:
> In article <4e25d86a$0$1975$bbae4d71@news.suddenlink.net>,
> Bill Cunningham <nospam@nspam.invalid> wrote:
>> blmblm@myrealbox.com wrote:
>>> In article <4e24a90b$0$8602$bbae4d71@news.suddenlink.net>,
>>> Bill Cunningham <nospam@nspam.invalid> wrote:
>>>> John Gordon wrote:
>>>>> In <4e24a281$0$1929$bbae4d71@news.suddenlink.net> "Bill
>>>>> Cunningham" <nospam@nspam.invalid> writes:
>>>>>
>>>>>> I want to take a 700MB file and skip evey 200MB, so I thought
>>>>>> of this.
>>>>>
>>>>> You mean you want to copy the 700MB file to another file, omitting
>>>>> 200MB chunks?
>>>>>
>>>>>> long * space=malloc(sizeof(long)*500000);
>>>>>
>>>>> There's no need to allocate that much space for a simple copy
>>>>> operation.
>>>>> You can copy, say, 8K or 16K at a time without allocating a huge
>>>>> buffer.
>>>>
>>>> I actually wanted to do something a little more difficult than
>>>> just copy the file. Every 200MB I want to save in a buffer about 8
>>>> bytes of data and exchange 0x0000 for it. It doesn't have to be
>>>> every 200M but it's such a large file I thought of 200MB. Not using
>>>> malloc() makes things so much easier. It doesn't have to be exactly
>>>> 8 bytes it could be 32. The important thing is to correctly store
>>>> the data read and save it correctly so it could be put back.
>>>
>>> Do you have some end goal in mind, or are you doing this because it
>>> somehow strikes you as an interesting or entertaining problem in its
>>> own right? I can't make much sense of the above description and am
>>> (mildly) curious.
>>
>> Please don't say "don't reinvent the wheel" it's all been done.
>> Everything is a learning experience. By punching "holes" in a file
>> you make it unreadable. By saving that information and reinserting
>> it it becomes readable again.
>
> Oh! Okay, well, that's not a task I'd have set myself, but this
> description is *almost* enough for me to imagine what the code
> might be like, and I guess I can sort of understand how it might
> seem like an interesting problem. (Depending on what kind of file
> it is, just replacing some of the data might or might not make it
> totally unreadable. But that may not matter to you.)
>
> One question you might ask yourself is where you're going to
> save the data you overwrite and want to put back later -- will
> it go in some separate file, or in some predetermined place in
> the original, or what?

Exactly. I was thinking about saving it in another file. This would be
to complicted for me to simply put into main() and I would have to break it
down into function. I can almost imagine how to do it. I'm not bad with C
functions; the ones I use mostly but counting and reading and writing would
be more complicated for me.

Anyway. Interesting learning experience.

Bill

Bill Cunningham

7/22/2011 3:26:00 PM

0

blmblm@myrealbox.com wrote:

> Oh! Okay, well, that's not a task I'd have set myself, but this
> description is *almost* enough for me to imagine what the code
> might be like, and I guess I can sort of understand how it might
> seem like an interesting problem. (Depending on what kind of file
> it is, just replacing some of the data might or might not make it
> totally unreadable. But that may not matter to you.)
>
> One question you might ask yourself is where you're going to
> save the data you overwrite and want to put back later -- will
> it go in some separate file, or in some predetermined place in
> the original, or what?

I think I will store it at the end of the file. I will create a 32-bit
"streak" that goes down the middle of a file and save what is written to a
buffer and put it at the file's end. This would involve a struct wouldn't it
for a type of header or footer. That's a lot of data to be writing. I want
one function to read this, one to write, and main() in there.

Bill