Bezpečný zápis souboru – C / C++ – Fórum – Programujte.com

Ahoj, potřebuji co nejbezpečnější zápis do souborů, zároveň nechci aby se (jestli to má nějaký vliv) zkracovala životnost disku.

Mám dva typy souborů:

1. typ: chci poměrně často a dlouho (3x - 50x za den, denně několik let, 16 bajtů) připisovat data na konec souboru (takovýchto souborů je ve složce několik tisíc, ale denně se mění max 50 souborů). 

2. typ: jsou dva soubory, které se budou zvětšovat 0x - 20x za den o asi 1440 bajtů a asi 10x - 50x za den se budou některé části přepisovat. (tyto budou používány pravděpodobně taky několik let)

Moc nerozumím defragmentaci, systému souborů a šetření pevného disku, tak se chci zeptat jestli je dobré prostě otevřít soubor pomocí fopen s "rb+" / "a" nebo vždy kombinací s temp souborem znovu zapsat celý soubor s atributem "w" ?

Soubory jsou samozřejmě zálohovány po síti, ale přesto bych se rád vyhnul problémům s obnovováním.

#1 BDS
já si myslim, že nic jako úsporný zápis neexistuje..

1) pokud to zapíšeš vždy na konec souboru, tak soubor prostě otevři, nastav pointer na konec a zapiš

2) to samé jako u (1) jen s tím rozdílem, že pokud budeš chtít zapisovat jen určité části, tak opět nastavíš pointer na tu část, kterou chceš přepsat

co se týče toho tempu souboru, tak to je jediný úskalí, ten bych nedělal asi vůbec když to stejně zálohuješ po síti

lepší úspora snad neexistuje, rohodně nepřepisovat celý soubor :)

defregmentace je zbytečná, nikdy jsem ji nepoužil a ani nepoužiju, rozdíl nepoznáš.. nebo spíš to by disk musel být pořádně zas** několik let, abych pro dobrý pocit pustil tento nástroj a jen sledoval jak se graf barevně sjednocuje

velikost na disku zalezi na velikosti bloku a velikosti souboru... kdyz mas milion souboru po jednom bajtu, a alokacni jednotku 32kB, tak kazdy soubor zabere nejmin 32kB...

mam treba "databazi" informaci v jsonu na disku, po souborech, a zabira to asi 100MB...

nicmene kdyz sem to same dal do kyoto tycoonu nebo redisu, tak to zabira asi pul mega ramky (+ je to zalohovany a tak, da se udelat i master slave replikace, takze bys pouzival master, slave by to zalohoval)

Děkuji za odpovědi.

A ještě se zeptám:

Potřebuji ještě udělat databázi asi 200 000 JPG obrázků (velikost 20-30 kB), běžně se k nim nebude přistupovat přes Explorer, ale budou sloužit jen jako náhledy, které bude zobrazovat (případně je upravovat) má aplikace, ta k nim bude automaticky přistupovat, uživatele nebude zajímat kde se který soubor nachází.

Mám tyto soubory házet do jedné složky, nebo by jste je raději rozložily do několika složek? Je to aplikace pro Windows XP a novější.

#4 BDS
těžko říct.. 200k souboru je poměrně dost a na jeden adresář až moc podle mě, ten adresář snad ani systém nemá šanci otevřít během pár sekund (NTFS zvládá snad 4.5M souborů na adresář)

pokud máš nějaký klíč, podle kterého to třídit, tak bych to třídil (třeba datum, typ, velikost, ...) nebo to rozházet po balíkách (max ~10k na složku)

pro aplikaci je to jedno, jestli jich je 200k nebo milion v adresáři, ale z pohledu systému a případný práce mi to přijde nepříjemný mít tolik souborů v adresáři

kdyby si to nepotřeboval zobrazovat na stránce, tak bych ti poradil to dát za balíku (třeba zip nebo jiný, aby si nemusel vymýšlet vlastní alg.)

ale je to můj názor, klidně to můžeš mít v jednom, systém to zvládne

#5 ingiraxo
Díky moc.

Taky si myslím, že to bude lepší, zvlášť když jsem ještě nikdy v jedné složce tolik souborů nikdy neviděl.

Jako asi nejrozumnější řešení bych viděl mít ty obrázky v nějakých databázových souborech, ale bylo by to složité při editaci některého z obrázku, protože u JPGu se mění velikost souboru v závislosti na barvách (všechny obrázky budou mít stejný rozměr 220x220px) . Takže roztřídění souborů do složek bude rozumné, zvlášť, když někdo bude chtít procházet složky. Pro mě to znamená jen, trochu práce navíc.

#6 BDS
noo to by byla další možnost - mít to uložený v DB jako bloby, pro procházení a vyhledávání to je jednoznačně rychlejší, kór když to o indexuješ.. editace přes app je taky v pohodě, stejně to načítáš ze souboru do streamu

pro web je to taky rychlý, akorát je to ze strany app pracnější (musíš vyřešit načítání a update záznamu do DB)

na tomhle řešení se mi jen nelíbí, že si nemůžeš ty náhledy procházet ručně, protože všechno bude binárně v DB.. ale pokud to stačí, tak proč ne