Prosty archiwizator - jaki format dla pliku z archiwum?

0

Cześć!

Mam do napisania prosty archiwizator w C wykorzystujący algorytm RLE (sprawdza czy kolejne bajty są identyczne), który łączy n plików w jeden. Jako bonus program ma archiwizować rekurencyjnie całe drzewo katalogowe.

Zastanawiam się jaką strukturę pliku spakowanego powinienem zastosować?

0

np.

  1. nagłówek
    a) jakiś stały identyfikator
    b) ilość plików
  2. pojedynczy plik
    a) długość nazwy
    b) nazwa
    c) rozmiar danych
    d) dane

plus taki, że bez problemów możesz dodawać/usuwać na końcu (nie musisz zmieniać nic poza nadpisaniem 1.b. co nie zmieni Ci porządku w pliku, tak samo usunięcie/zmiana pliku ze środka powoduje jedynie przekopiowanie pozostałych danych ale nie rusza tych wczeniejszych (oprócz 1.b.). Minus jest taki, że żeby odczytać 10 plik musisz znaleźć najpierw 1, 2, 3, ... 9 (ale nie musisz ich odczytywać a jedynie ich rozmiary)

0

możesz też w nagłówku umieścić drzewo archiwum, coś w stylu
ścieżka w archiwum -> nazwa pliku -> identyfikator -> offset w archiwum
i będziesz mógł zarówno dodawać na końcu z małą tylko modyfikacją drzewa, jak i od razu odnaleźć plik poprzez przeszukanie całego drzewa

0
dodekam napisał(a)

możesz też w nagłówku umieścić drzewo archiwum, coś w stylu
ścieżka w archiwum -> nazwa pliku -> identyfikator -> offset w archiwum
i będziesz mógł zarówno dodawać na końcu z małą tylko modyfikacją drzewa, jak i od razu odnaleźć plik poprzez przeszukanie całego drzewa
jeśli przepisywanie prawie całej zawartości pliku to wg. Ciebie mała modyfikacja to co jest dużą?

0
Misiekd napisał(a)
  1. pojedynczy plik
    a) długość nazwy
    b) nazwa
    c) rozmiar danych
    d) dane

Rozmiar danych pojedynczego pliku nie będzie znany przed samą kompresją, nie wiadomo też na ilu bajtach zapisać taki rozmiar.
Spróbuje chyba zastosować znak specjalny np. #. Jeśli treść pliku zostanie zinterpretowana jako # zapiszę w pliku wynikowym ##, podobnie jak znak specjalny \ w C.

0

nie nie nie. nawet nie myśl o zapisie tekstowym, później odczyt z takiego pliku bajt po bajcie to porażka. wiadomo na ilu bajtach zapisać rozmiar - na czterech, bo chyba z więcej niż 2GB nie będziesz pracować. To że nie znasz rozmiaru nic nie znaczy. jak nie znasz rozmiaru danych, to zapisujesz do pliku na końcu long wynoszący 0, kompresujesz doklejając kolejne dane, a na końcu seek do miejsca z długością i nadpisujesz zero długością, którą już znasz. i tam z każdym kolejnym plikiem, co w efekcie da ci układ bloków miśka.

0
Łukasz1111 napisał(a)

nie wiadomo też na ilu bajtach zapisać taki rozmiar.

Ranides napisał(a)

wiadomo na ilu bajtach zapisać rozmiar - na czterech, bo chyba z więcej niż 2GB nie będziesz pracować.

dla pewności na 8 - int64 jest chyba w każdym języku programowania a wielkości 16777216TB dłłłuuuggooo nie przekroczysz

//q:nie chcę nic mówić, ale nie tak dawno to samo mówiono o lowram 640kB, chwilę potem o dyskach 800mb i teraz obecnie o dyskach 500gb.. które moi znajomi juz dawno zapchali:)

1 użytkowników online, w tym zalogowanych: 0, gości: 1