c++/файлове windows

имам файл от тип std::fstream и преди да го затворя искам да отрежа няколко Кбайта от началото му и от края. Не мога да използвам МФЦ, с Win32 би трявало да стане с ::SetFilePointer, но трябва тепърва да го ре-отварям. За рязането от началото изобщо не съм сигурен дали е възможно. Някви идеи.. по възможност със стандартната библ или в краен случай с win32 api?

Благодаря ви

Но и аз подкрепям питането. Ако знае някой как да каже. Аз не можах да го резна файла по никакъв начин (освен с ампутация). Спомням си, че навремето имах обратния проблем - тогава не успявах да пиша през средата. Голяма мъгла са ми тия файлове.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

ас се сещам за Memory-Mapped Files
[линк]

другото е стандартното да чегарташ по фаил-а сас fseek

Началото не може да се реже, освен както казва Колумбино с ампутация.

Края:
С Win32 API e със SetEndOfFile.
СRTL : chsize

Сигнатура!

Абе зарежете API-то и C-то. С тях всеки може. Кажете как се прави със стандартната библиотека на C++. Няма начин да няма начин, но аз не можах да го открия.
А тва дето вика KpyM за seek и ние се сещаме, само дето като се затвори, файла си остава цял след пойнтера (със и без писане във файла). Аз ли не го отварям правилно (in|out|bin), библиотеката ли пак я е хванало сечението ( най-малко общо кратно ), ама не открих как се прави.


System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Ами аз подходих 'алтернативно' - потърсих из сорса за SetEndOfFile...

Сигнатура!

за fseek се оказа че тряба да сложиш _chsize на края за да го изреже

fstream::fd - с нея може да вземеш файл-дескриптора и да ползваш CRTL.....

Това ти е програмката на C++. Работи от командия ред. Първият параметър е целевия файл, втория параметър е броя на байтовете за отрязване от началото и края. Първо се отрязват началото и края на потока и се копират в масив и след това се връща обратно. После се оправя размера на файла.

//Cut.cpp
#include "stdio.h"
#include "stdlib.h"
#include "io.h"
#include "stdlib.h"
#include "ctype.h"

void main(int argc, char *argv[] )
{
char *buf;
FILE *stream1;
long offset;
long FileLength,BufLength;
int result,fh;

if(argc!=3)
{
printf("Usage: Cut <file path> <integer offset> \n");
exit(1);
}
offset = atol(argv[2]);
if(offset == 0)
{
printf("The second parameter must be integer! \n");
exit(1);
}
if((stream1 = fopen( argv[1], "r+b" )) != NULL)
{
fh = _fileno(stream1);
FileLength = _filelength(fh);
if(offset >= FileLength/2)
{
printf("The offset is too long!");
exit(1);
}
buf = (char*)malloc(FileLength);
BufLength = FileLength-(offset*2);
fseek(stream1,offset,SEEK_SET);
for(int i=0;i<BufLength;i++)
{
buf=fgetc(stream1);
}

fseek(stream1,0,SEEK_SET);

for(int i=0;i<BufLength;i++)
{
fputc(buf,stream1);
}
if( ( result = _chsize( fh, BufLength ) ) == 0 )
printf( "Size successfully changed\n" );
else
{
printf( "Problem in changing the size\n" );
fclose(stream1);
exit(1);
}
fclose(stream1);
}
else
{
printf("Cannot open input file!");
exit(1);
}
}

Само да поправя:
Реда buf=fgetc(stream1); е
buf = fgetc(stream1);
Реда fputc(buf,stream1); е
fputc(buf, stream1);
И махни единия stdlib.h. Всичко друго е OK.

Явно колегата се e мъчил да напише "buf [ i ]", но това съвпада с тага за italic.

Ami maj naistina shte ti se naloji da go otworish
eto edin variant kojto shte mine spored men:
dobre si se nasochil kym SetFilePointer
taka che ideiata e da wzemesh taja chast ot stream-a koiato ti triabwa i da ia save-nesh w drug stream - da otrejesh nachaloto i kraja. Ne znam towa dali shte ti wyrshi rabota no vyrwi taka ili inache. A drugia wariant e da go save-nesh w segashnoto mu systoianie, a reader-a na stream-a da ne chete pyrwite i poslednite bajtowe kakto ti iskash.

това fstream::fd не е ли също от CRTL fstream.h, тоест не е от <fstream> ..и след като имам указател от STL обект няма как да извикам fd().
Вие с каква цел изобщо ползвате STL, аз установих, че примерно някой прост клас като CStdString ми е по-удобен от basic_string (който ми свърши огромна работа само веднъж като като трябваше да права едни Юникод преобразувания на Уин95 ,..), сега нещо и с файловете пак не мога да мина без функции от "по-ниско" ниво, STL има готини контейнери де, а за стандартните им алгоритми наскоро не съм ги пипвал ... вие?

Тошко мерси много за програмата :)
чесно казано и аз бях нашисал нещо подобно, не исках да ползвам АПИ. Бях заменил fgetc цикъла с блоково четене в буфер, но проблема при този метод е че не мога да си позволя и алокиране на буфер колкото файла ми, съответно не мога и да отрежа файла от началото. Всъщност аз записвам едни МП3 песни и понеже имам много тредове. които могат едновременно да алокират памет и буферите ще станат много "алокиращи".. :) освен това , процесът е критичен и по време ...

да то seek просто позиционира за четене. запис и пр.
За тези Мап файлове .. нещо много дълга ми се видя статията и малко ме домързя да я чета, но предполагам тва ще е пак наква "сериализация" на микрософт дето само време ще гълта..
Иначе мерси за инфото :)

"Началото не може да се реже, освен както казва Колумбино с ампутация." .. знам . знам :((
все пак мъничко се надявах да се заблуждавам, та за тва и "постнах" съобщение ...пък и ми беше любопитно за СТЛ ф-иите

Може да се замислиш да ги записваш тия mp3 в
виртуална файлова система

не вярвам някъде да има отрязване на началото
обикновено файла заема някякви блокове, които са
най-малката адресируема единица, това че последният
блок не е пълен е естествено състояние, но файловете
винаги започват от началото на първия блок
тогава може да се реализира лесно отрязване само
на кратно на блока парче, което обезсмисля усилието

Memory mapped files не е пак някаква "сериализация" на Майкрософт, а нещо, което присъства във всички уважавани операционни системи, поддържащи виртуално адресно пространство, в това число повечето съвременни Unix деривати (където механизмът на мапинга в паметта в комбинация с позиционно независимият код е в основата на динамичните поделени библиотеки /еквивалента на DLL/).

Най-просто казано, процесът позволява задаването на еднозначно съответствие между страници от виртуалната памет и блокове от дисков файл. От програмистка гледна точка получаваш указател към блок в паметта, съответстващ на парче от файла (евентуално на целият файл), при което заместваш операциите четене и писане във файл с четене и писане в паметта. Страшно удобно, тъй като можеш да си кастнеш указателя към произволен тип и да имаш структуриран достъп до съдържанието на файла без да четеш и пишеш в буфери. Особено полезно при обработката на гигантски файлове.

"Всички науки са или физика, или колекциониране на пощенски марки." (Е. Ръдърфорд)

Аз правя програма за звук и запис на непрекаснат поток музика (в частност МП3). Файловете се налага да ги режа защото то е поток и аз определям кога почва нова песен. Аз си го бях направил всичко готино работещо, но както обикновено в последния момент ми промениха някой параметри (юзера да си задава там едни времена), от които за мен следваше още едно допълнително орязване. Беше малко гадно, защото се наложи да го променям в последните 2-3 часа и сега например ще видя как ще работи за ОГГ, ама кво да правя като шефовете ми не са чували за предварителен проект/дизайн/ на приложението :( ПРоблема е че преди да съхраниш примерно песен не знаш кога ще свърши за да спреш да записваш 10 сек преди това. То има много решения, запис със закъснение, буфериране (което вчера направих и сега всичко си бачка), ама е гадно като трявба да правиш нещо такова за една вечер и тва с файловете беше просто кръпка :)
Иначе тва за жиртуалната система ми е интересно какво имаш в предвид, макар и да не ми трябва :)

намам си понятие от Уникс, а за мемори файловете звучи готино наистина(може дори и да съм го ползвал ;)
не ми става ясно дали с тази технология мога да променям и размера, да кажем искам да поорежа Н_тия блок, или да увелича някой друг (по размер).
Освен това ако в момента създаваш и постоянно пишеш в 10тина файла ти не може постоянно да ги мапваш.
Иначе от сега виждам много приложения на това за редактиране на вече създадени файлове ... един вупорс: този процес на мапване и адресация в файловете отнема ли много вре,е?