Jak programowo utworzyć plik C w systemie Mac OS X?

Question

Chciałbym utworzyć plik rzadki tak, aby wszystkie bloki zerowe nie zajmowały rzeczywistej przestrzeni dyskowej, dopóki nie zapiszę do nich danych. Czy to możliwe?

Answer 1

Podobnie jak w innych Uniksach, jest to funkcja systemu plików. Albo system plików obsługuje go dla WSZYSTKICH plików, albo nie. W przeciwieństwie do Win32, nie musisz robić nic specjalnego, aby to się stało. Również w przeciwieństwie do Win32, nie ma kary za wydajność w przypadku używania pliku rozrzedzonego.

W systemie MacOS domyślny system plików to HFS +, który obsługuje , a nie pliki pomocnicze w postaci sparse.

Aktualizacja: MacOS używany do obsługi woluminów UFS z nieobsługiwaną obsługą plików, ale został usunięty. Żaden z obecnie obsługiwanych systemów plików nie obsługuje obsługi plików rozproszonych.

Answer 2

hdiutil może obsługiwać rzadkie obrazy i pliki, ale niestety struktura, z którą się łączy jest prywatna.

Możesz spróbować zdefiniować zewnętrzne symbole zdefiniowane przez framework DiskImages poniżej, ale jest to najprawdopodobniej niedopuszczalne dla kodu produkcyjnego, a także dlatego, że framework jest prywatny, musisz odwrócić jego przypadki użycia.

Cristi: ~ diciu $ otool -L/usr/bin/hdiutil

/usr/bin/hdiutil: /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages (wersja 1.0 Kompatybilność .8, obecna wersja 194.0.0) [..]

cristi: ~ diciu $ nm /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages | awk -F '' '{print $ 3}' | C++ filt | grep -i rzadki

[..]

CSparseFile :: sector2Band (długie długości)

CSparseFile :: addIndexNode()

CSparseFile :: readIndexNode (długie długości SparseFileIndexNode *)

CSparseFile :: readHeaderNode (CBackingStore * SparseFileHeaderNode *, unsigned long)

[... cięcia dla zwięzłości]

Później Edit

Ty mógł użycie hdiutil jako proces zewnętrznego i mieć go utworzyć rzadki obraz dysku dla Ciebie. Z procesu C utworzysz plik w (zamontowanym) rzadkim obrazie dysku.

Answer 3

Jeśli chcesz przenośność, ostatnią deską ratunku jest napisanie własnej funkcji dostępu, aby zarządzać indeksem i zestawem bloków.

W istocie zarządzasz pojedynczym plikiem, ponieważ system operacyjny zarządza dyskiem, zachowując łańcuch bloków, które są częścią pliku, mapę bitową przydzielonych/wolnych bloków itp.

Oczywiście doprowadzi to do niezoptymalizowanego i wolniejszego dostępu, polecam ten apprach tylko wtedy, gdy wymóg oszczędzania miejsca jest absolutnie krytyczny i masz wystarczająco dużo czasu, aby napisać solidny zestaw funkcji dostępu.

I nawet w takim przypadku najpierw sprawdziłbym, czy twój problem wymaga innego rozwiązania. Prawdopodobnie powinieneś inaczej przechowywać swoje dane?

Answer 4

Jeśli szukasz (fseek, ftruncate, ...) do końca, rozmiar pliku zostanie zwiększony bez przydzielania bloków, dopóki nie napiszesz do dziur. Ale nie ma sposobu, aby utworzyć magiczny plik, który automatycznie konwertuje bloki zer do dziur. Musisz to zrobić sam.

Może to być pomocne przy patrzeniu (polecenie OpenBSD cp wstawia otwory zamiast zapisywania zer). patch

Answer 5

Wydaje się, że istnieje pewne niejasności co do tego, czy domyślny system plików Mac OS X (HFS +) obsługuje otwory w plikach. Poniższy program pokazuje, że tak nie jest.

#include <stdio.h> 
#include <string.h> 
#include <fcntl.h> 
#include <unistd.h> 

void create_file_with_hole(void) 
{ 
    int fd = open("file.hole", O_WRONLY|O_TRUNC|O_CREAT, 0600); 
    write(fd, "Hello", 5); 
    lseek(fd, 99988, SEEK_CUR); // Make a hole 
    write(fd, "Goodbye", 7); 
    close(fd); 
} 

void create_file_without_hole(void) 
{ 
    int fd = open("file.nohole", O_WRONLY|O_TRUNC|O_CREAT, 0600); 
    write(fd, "Hello", 5); 
    char buf[99988]; 
    memset(buf, 'a', 99988); 
    write(fd, buf, 99988); // Write lots of bytes 
    write(fd, "Goodbye", 7); 
    close(fd); 
} 

int main() 
{ 
    create_file_with_hole(); 
    create_file_without_hole(); 
    return 0; 
} 

Program tworzy dwa pliki, każdy 100000 bajtów, z których jedna posiada otwór 99,988 bajtów.

W systemie Mac OS X 10.5 na partycji HFS +, oba pliki zajmują tę samą liczbę bloków dyskowych (200):

$ ls -ls 
total 400 
200 -rw------- 1 user staff 100000 Oct 10 13:48 file.hole 
200 -rw------- 1 user staff 100000 Oct 10 13:48 file.nohole

Zważywszy na CentOS 5, plik bez otworów zużywa 88 więcej bloków dyskowych niż drugi:

$ ls -ls 
total 136 
24 -rw------- 1 user nobody 100000 Oct 10 13:46 file.hole 
112 -rw------- 1 user nobody 100000 Oct 10 13:46 file.nohole

Answer 6

Ten wątek staje się kompleksowym źródłem informacji o plikach rozrzedzonych. Oto brakujące części dla Win32:

Decent article with examples

Tool that estimates if it makes sense to make file as sparse

Pozdrowienia

Answer 7

to wygląda OS X obsługuje rozrzedzone pliki na woluminach UDF. Wypróbowałem program testowy tyaniumdecoy na OS X 10.9 i wygenerowałem rzadki plik na obrazie dysku UDF. Ponadto, nie UFS nie jest już obsługiwany w OS X, więc jeśli potrzebujesz plików sparse, UDF jest jedynym natywnie obsługiwanym systemem plików, który je obsługuje.

Próbowałem również programu na udziałach SMB. Gdy serwer jest Ubuntu (ext4 system plików), program tworzy plik rozrzedzony, ale "ls -ls" do SMB tego nie pokazuje. Jeśli robisz "ls -ls" na samym hoście Ubuntu, pokazuje on, że plik jest rozrzedzony. Gdy serwer jest systemem Windows XP (system plików NTFS), program nie generuje rozrzedzonego pliku.