![]() |
To jest zwykły overbiuring z (subkanałami - czy jakoś tak), odwołania na CD są do subkodów i przy kopiowaniu ich na dysk przegrywasz je. Clonem da to się przegrać nie zaznaczając żadnych opcji. :P
Mogę się mylic co do subkodów (( |
Cytat:
Ciekawe, czy ktoś akurat w tym przypadku nie dał jakiejś kompresji, która jest "w locie" odczytywana po włożeniu płyty do napędu. Miłego dnia |
Cytat:
|
takiej postaci linki o ktorych mowisz sa tylko w ssytemach unixowych...
przyznaje ze nie wiem w czym problem - ale jesli clone ci przegrywa dobrze - to zapomnij o problemie |
Cytat:
Pozdrawiam. |
i wracajac do tematu - bylo sobie kiedys takie zabezpieczenie - illegal TOC - polegalo na tym ze manipulujac wpisami do Table of Contents zmienialo sie rozmiar (dowolnego) pliku np. z 1kb do 2gb - plyta sie nagrywala dobrze - potem kazdy kto chcial sie bawic w przegrywanie albo uzywal klona albo mial problem - mozliwe ze ten myk zastosowano i tutaj - obejzyj czy ktorys z teoretycznie malych zbiorow nie jest BARDZO duzy - np. jakis help czy cos...
|
Ilość załączników: 1
No ale size to rozmiar plików (1), a size on disk to miejsce zajmowane na dysku (2). Przynajmniej mi się tak wydaje.
|
kompresja dysku to sztuczne obejscie problemu - SYSTEM zapisuje zupe plikowa tak jakby do jedneko pliku - eliminujac w ten sposob straty zwiazane z kwantowaniem danych do co najwyzej jenego sektora - jednak dysk ciagle siega pod konkretne adresy - ktorych nie przybylo - kozysc oczywista, jest tylko jeden zonk - system SPORO sie musi napracowac zeby to obsluzyc
tak dzieje sie w przypadku FATow 16 i 32 NTFS ma wbudowana kompresje i tam ten problem nie istnieje - przynajmniej nie w takim stopniu jak jest w li(uni)ksach nie wiem - podejzewam ze ze wzgledu na szybkosc dzialania (kluczowe w zast sieciowych) wybiera sie jakis kompromis |
Cytat:
|
podzial dysku na jednostki adresowe o skonczonej pojemnosci wynika z faktu ze ktos gdzies dawno temu wymyslil tylo-a-tylo bitowe adresowanie - dopoki dyki mialy po 100mb wszystko bylo ok - kiedy pojawily sie 8, 10, 20 i wyzej gb- okazalo sie ze adresow ejst tyle samo - dlaczego jest to takie wazne? bo zeby poprawnie czytac zawartosc dysku musisz podac adres - a im wiekszy dysk tym wieksze musza byc najmniejsze jednostki adresowalne (bo adresow nie przybywa)
stad powszechny zwyczaj dzielenia na partycje - bo poza wygoda, daje to tez znaczace zmniejszenie rozmiaru tego najmnijeszego kawalka |
może jest dużo małych plików na cd
jak wiadomo płyta ma nną konstrukcję i podział dysk ma klastry 0,5 - 64 kb płyta nie wiem, ale musi mieć albo dużo mniejszy albo dużo większy podział... nie jestem pewien np. jeżeli masz na hdd 4kb klastry to bardziej oszczędzasz miejsce jeżeli masz dużo małych plików... np. jeżeli masz plik 7 kb a 4-kilowe klastry to plik zajmie je oba i 1 kb się marnuje, a jeżeli miałbyś plik np. 33 kb a 32kb klastry to plik ten zajmie 1 klaster 32kb i drugi też... zmarnuje się 31kb :) nie wiem czy nie zamieszałem za bardzo :) |
Ilość załączników: 1
kurcze wybaczcie ale jestem tu nowy ((
|
Ilość załączników: 1
hmm chyba o czyms zapomialem:
|
Tego to jeszcze chyba niewidzieliscie :D
Witam
Sprawa wyglada tak: Posiadam instalke Windy Xp z licencja MSDN, na plytce tej jest i win xp Pro i HE. Jak klikne prawym przyciskiem myszy na ikonie cd-romu to i wybiore wlasciwosci to pokazuje ze na plycie jest 517MB (1.jpg) a jak otworze plyte i wcisne CTRL+A i wybiore wlasciwosci to pokazuje ................ 965MB !!!!!!!!!!!!!!!! (2.jpg) Jak skopiuje pliki na HD to jest ich ................... 965MB!!!!!!!!!!!! (3.jpg) Co by niebyc goloslownym to zalaczam print screen-y 8) A i to niejest jakies tam bledne wyswietlanie windy, u moich kumpli jest tak samo. :P Hehe i co Wy na to???? Moje zdanie jest takie ze pliki do win xp pro i HE sie powtarzaja wiec w katalogu np. WXPRO sa fizycznie pliki a w katalogu WXHE sa tylko "odwolania" do plikow w katalogu WXPRO, a moze to jakas najnowsza odmiana overburningu :-D Pozdrawiam |
| Wszystkie czasy w strefie CET. Aktualna godzina: 14:12. |
Powered by vBulletin® Version 3.9.0 LTS
Copyright ©2000 - 2026, vBulletin Solutions Inc.