какие апи юзать чтоб писать/читать сектора?

Хм. А ведь во втором случае это работа с физическим устройством. Разве гарантируется, что система будет проверять, не адресуемся ли мы за пределы его?

 

Скорее всего так и есть. Но Skif утверждает, что у него работает по другому. В MSDN про это не нашел ничего :-(

 

У Skif ведь логические устройства.

Хотя нет. У него там это не определено: путь берётся из командной строки

 

Хм. Только что проверил mkimage.exe \\.\PhysicalDrive1 flash.img, где PhyscialDrive1 - 128-и мегабайтная флэшка. Получился образ размером 128 мб., ReadFile() вернула false, GetLastError() -> 1117 (The request could not be performed because of an I/O device error).



Т.е. чтение все-таки останавливается хотя и не так, как об этом сказано в MSDN (должно быть TRUE и lpNumberOfBytesRead -> 0 соответственно).



Для поставленной задачи IMHO вместо \\.\PhysicalDriveX можно использовать \\.\X:, для которого всё работает.

 

В поставленной задаче из \\.\PhysicalDriveX и \\.\X читаются разные данные.

И поведение на различных флэшках разное - странно. Может быть дело в ОС? Я проверял на XPSP2.

 

Разумеется, данные разные (для \\.\PhysicalDriveX чтение начинается с MBR, в случае \\.\X: читается логический том, начиная с его boot record).



Хотя, м.б. я не прав, и действительно стОит копировать флэшки начиная с MBR (я рассматривал только копирование логических томов между одинаково отформатированными флэшками одинакового размера).



PS. ОС - Win2k SP4.

 

а толку мне копировать с бут рек. мне нуна дампить флешки с непонимаемым системой форматом. так что приходится ручками указывать скока мегов дампить. впрочем это удобно с помощью моей тулзы можно теперь дергать-вставлять проивольные куски из файлов и дисков что тоже оч неплохо.

 

если указывать "\\.\A:" то чтение идет нормально (WinXP), если указываю "\\.\PHYSICALDRIVE0",то читает с жесткого, а если другие цифры подставляю, то ошибку выдает. Что за хрень?

 

doctor_Ice, Дата: Авг 8, 2005 09:57:57



OK, тогда смотреть в сторону IOCTL_DISK_GET_DRIVE_GEOMETRY. При его применении к \\.\PhysicalDriveX получаем структуру

Код (Text):

1.  
2. typedef struct _DISK_GEOMETRY
3. {
4.     LARGE_INTEGER Cylinders;
5.     MEDIA_TYPE MediaType;
6.     DWORD TracksPerCylinder;
7.     DWORD SectorsPerTrack;
8.     DWORD BytesPerSector;
9. }DISK_GEOMETRY;
10.  

которая описывает, очевидно, "геометрию" физического диска. Его размер в байтах получается как Cylinders.QuadPart*TracksPerCylinder*SectorsPerTrack*geometry.BytesPer Sector.



PS. Кстати, если, например, \\.\Z: - том на физическом диске \\.\PhysicalDriveN, то IOCTL_DISK_GET_DRIVE_GEOMETRY для \\.\Z: вернет параметры \\.\PhysicalDriveN. Так что использовать этот прием нужно осмотрительно

 

yureckor



А "другие цифры" у тебя в системе-то есть? )) \\.\PhysicalDriveN представляет собой n-ый физический диск, установленный в системе.

 

Skif

floppy, hd, cd.

Только какого жесткий считывается по PhysicalDrive0 ?

а вообще я от 0 до 9 перебрал, ничего.

 

а как это перевести:

Код (Text):

1. #define IOCTL_DISK_GET_DRIVE_GEOMETRY   CTL_CODE(IOCTL_DISK_BASE, 0x0000, METHOD_BUFFERED, FILE_ANY_ACCESS)
2.  

и еще MEDIA_TYPE - это BYTE или DWORD ? (в *.h файле стоит enum на 1.5 десятка значений)

 

Значит BYTE. enum <256 это байт.

 

n0name

не, оказалось DWORD.

Вот, немного вручную перегнал из VC60





1708412102__winioctl.rar

 

yureckor

Вопрос я немного не понял, но попытаюсь пояснить свой предыдущий пост. При инициализации дисковой подсистемы создаются символические ссылки на устройства. Нумерация начинается с 0. Т.е. создаются PhysicalDrive0, PhysicalDrive1, ..., PhysicalDriveN, в зависимости от количества имеющихся в системе физических приводов (HDD в данном случае). Подробнее можно посмотреть в примерах NTDDK (.\src\storage\class\disk\...). Флэшки тоже умеют прикидываться шлангом, т.е. жестким диском. Так что, если в системе есть один физический жесткий диск, доступ к нему можно получить через \\.\PhysicalDrive0. При подключении флэш-накопителя появляется \\.\PhysicalDrive1, и так далее.



\\.\A:, \\.\B:, \\.\C: - это уже не физические устройства, а логические тома (разделы) на соответствующих устройствах (\\.\A: -> Device\Floppy0 и т.п.).



Подробнее - MSDN & DDK Documentation. Еще полезно почитать Windows Internals, там, как я помню, тоже есть про это.



Кроме того, на wasm.ru лежит замечательная утилита WinObjEx от Four-F. Там можно посмотреть, что есть, а чего - нету

 

всем привет а как вам такой прикол. сдампил я загрузочную флешку 32мег. закатал дамп на 128мег флешку. вышло вот что - размеченные данные 30 с копейками мег а остальное не размеченно те. все как и должно быть все файлики читаются. я уже подумал что все сухо и комфортно но стек переполнился втыкаю я свою клоновою 128 и она не грузится. вывод напрашивается сам собой - у флешек есть не только сектора но и цилиндры. я так понимаю файлы и фаты там всякие он находит потому что на них идет ссылка лог секто и тут все ок а вот бутылка ищет ио.сис по ссылка головка.цилиндр.сектор и тут об дает течь. попробую править лапками.

тут Skif

рассказывает о IOCTL_DISK_GET_DRIVE_GEOMETRY а че это за хрень куда это параметр пихать? в какую функцию?

 

doctor_Ice

1) Точно не уверен (знающие люди - поправьте), но вроде бы флэшки бывают загрузочные и незагрузочные чисто физически (по крайней мере на некоторых пишут bootable, на некоторых - нет). Попробуейте сделать 128-мб. флэшку загрузочной штатными средствами OS.



2) Если google.com все еще работает, то поиск по ключевому слову IOCTL_DISK_GET_DRIVE_GEOMETRY первой же строкой дает ссылку на сайт MSDN, про который я уже упоминал выше, где написано, что и куда "пихать" ))

 

yureckor

Зависит от выравнивания. Чаще получается действительно 4 байта

 

DeviceIoControl похоже. мсдн пока не качал но скачаю обязательно когда разберусь где что. там все на английском, а я слишком глуп для него.



штатные и не штатные средства ос не хотят иметь дело с флешкой просто жо какаято.



когда я втыкал клонированную флешку она выдал нон систем диск ор диск ерор это выдет бутылка биос матерится вроде иначе. а раз выдает бутылка значит она стартует но не находит ио сис. я наверное счас дизасмну бутылку и гляну куда она лезет и есть ли там ио.сис если как я думаю вся проблема просто в геометрии то я просто подправлю бутылку и все будет ок. тока для начала нуна поличить данные о геометрии. пока не разобрался как. или можно сис.ком подправить убрать проверку версии дос и тогда может тоже все будет ок.



<font color="red]используйте жаргонные термины только если уверены, что все заинтересованные понимают их</font><!--color-->

 

doctor_Ice

вот код, читает данные 2-18 дорожки (копии для надежности) с дискеты

Код (Text):

1.  
2. ;---
3. vzt_key proc adr_user:DWORD
4. Local l1_lc:DWORD
5. Local hfile_lc:DWORD
6. Local m1:strukt_memory
7. Local m2:strukt_memory
8. Local disk_struk_lc:DISK_GEOMETRY
9. Local razmer_lc:DWORD
10. pushad
11.  m_zero_strukt_memory m1
12.  m_zero_strukt_memory m2
13.  
14.  invoke copy_str, tx("Ошибка доступа к устройству."), OF buf_otvet
15.  invoke CreateFile,tx("\\.\A:"),\ ;"\\.\PHYSICALDRIVE0" "\\.\A:"
16.          GENERIC_READ,FILE_SHARE_READ or FILE_SHARE_WRITE,\
17.          NULL,OPEN_EXISTING,FILE_ATTRIBUTE_ARCHIVE,NULL
18.  CP eax,INVALID_HANDLE_VALUE,z,@@10
19.  mov [hfile_lc],eax
20.  invoke DeviceIoControl, [hfile_lc], IOCTL_DISK_GET_DRIVE_GEOMETRY, \
21.   0, 0, ADDR disk_struk_lc, SIZEOF disk_struk_lc, ADDR l1_lc, 0
22.  .if eax==0
23.   mov PD [disk_struk_lc.Cylinders], 80
24.   mov PD [disk_struk_lc.Cylinders][4], 0
25.   mov [disk_struk_lc.TracksPerCylinder], 2
26.   mov [disk_struk_lc.SectorsPerTrack], 18
27.   mov [disk_struk_lc.BytesPerSector], 512
28.  .endif
29.  mov eax, [disk_struk_lc.BytesPerSector]
30.  mul [disk_struk_lc.SectorsPerTrack]
31.  mov [razmer_lc], eax
32.  
33.  invoke create_memory, ADDR m1, [razmer_lc]
34.  invoke create_memory, ADDR m2, [razmer_lc]
35.  invoke copy_str, tx("Нет ключа!"), OF buf_otvet
36.  ;пропускаю первые две
37.  call @@readtrack ;0
38.  CP eax, 21, Z, @@9
39.  call @@readtrack ;1
40.  CP eax, 21, Z, @@9
41.  ;со 2-ой по 18-ую
42.  mov edx, 16
43.  @@1:
44.   call @@readtrack
45.   jc @@2
46.   CP eax, 21, Z, @@9
47.  dnz edx, @@1
48.  invoke copy_str, tx("Не могу прочитать ключ!"), OF buf_otvet
49.  clc
50.  jmp @@9
51.  @@2: invoke copy_mem, [m1.mem], [adr_user], SIZEOF user_strukt
52.  invoke copy_str, tx("DA"), OF buf_otvet
53.  stc
54.  @@9:
55.  pushfd
56.  invoke CloseHandle,[hfile_lc]
57.  popfd
58.  @@10:
59.  pushfd
60.  invoke close_memory, ADDR m1
61.  invoke close_memory, ADDR m2
62.  popfd
63. jmp @@kon
64.  
65. ;-
66. @@readtrack:
67.  inva_win ReadFile, [hfile_lc], [m1.mem], [razmer_lc], ADDR l1_lc, NULL
68.  psh eax
69.  mov ecx, [disk_struk_lc.TracksPerCylinder]
70.  sub ecx, 1
71.  jc @@rt1
72.  jz @@rt1
73.  @@rt0:
74.   inv_win ReadFile, [hfile_lc], [m2.mem], [razmer_lc], ADDR l1_lc, NULL
75.  dnz ecx, @@rt0
76.  @@rt1:
77.  po eax
78.  .if eax==0
79.   inva_win GetLastError
80.   clc
81.  .else
82.   or eax, -1
83.   stc
84.  .endif
85. m_ret
86.  
87. @@kon:
88. @@100:
89. popad
90. ret
91. vzt_key endp
92.  

структуры и equ для MASM я выше бросал.