I wrote a tool which was originally thought for analyzing hard disc images. Now I'm trying to use this tool for live analyzis of computer systems, means my tool tries to access the physical drive.
I implemented my tool in QT accessing the images using the QFile class. Instead of images I hand over the physical drive, under windows it is \.\PHYSICALDRIVE0.
I was wondering first I didnt get any errors, I can open the device, I can seek, get the position, almost everything. The only thing I have problems with is retrieving the drive size with size().
Some code example:
QFile file( "\\.\PHYSICALDRIVE0" );
file.open( QIODevice::ReadOnly );
file.size(); //returns 0
I'm not too deep into QT, probably this is some easy thing. I would like to thank everybody who has an idea what is the reason.
thanks in advance!
QFileInfo may be able to help you out. It sounds like opening a read only file at that part of windows partition is allowed maybe even if it doesn't exist. There might be a chance that the call of GetLastError() may give more information why a file size of zero was returned.
With QFileInfo, you can check to make sure it exists before it opens.
You may end up needing some platform specific calls to be able to work with Physical Drives:
Volume to physical drive
It looks like there may be some example code of looking at partitions with PartMod on SourceForge.
As a side note of querying sizes of file folders, I thought it had to be cached somewhere by the operating system, or had to be calculated at the time of the query in many cases. I know it seems like that happens when looking at folder properties in Windows or Get Info on OSX.
Also, looking at the Volume to physical drive answers, there is a field there for the extent length. I think this is what you are looking for.
Hope that helps.
Related
This is really stumping me. I'm trying to recover some lost information (for reasons I cannot disclose) from a dump of an Android phone's free space. I have no lookup table for the disk, so all I have is the raw dump of the flash.
Basically, I'm trying to pick out SQLite files from this huge 350 megabyte mess. I can find the SQLite file header easy enough, it's 100 bytes and described here. Everything seems to be in place. However, I can find entries, but I'm currently stumped as to how to determine where the entries stop and the file ends and other sectors of the disk are filled.
Any suggestions? I'm at a dead end currently, other than kind of manually going through and trying to eyeball it, but I'm a programmer here, trying to find some sort of methodical way through this.
I appreciate you guys in advance!
I've always had luck recovering data using PhotoRec which, despite its name, supports many file formats including sqlite.
http://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec
I've never tried it on a dump of flash memory so I don't know how successful it would be. It depends on how the file is layed out in memory and PhotoRec bets on the fact that most files are stored in contiguous blocks (i.e. not fragmented).
for this example，from the Qt documentation , http://qt-project.org/doc/qt-4.8/network-download.html the program first read all data to the buffer ,then all data are written to the disk from the buffer ,right ?
then for this example，from the Qt documentation , http://qt-project.org/doc/qt-4.8/network-downloadmanager.html the program is reading and writing data all the time ,right ?
and which way is more proper ？
I dont think that 'more proper way' applicable in this case, they both have pro and cons and obviously depends on what you trying to build.
Depends what functionality you need. If you need only 'completed' items to be saved and their are size relatively small to be kept in memory you can first fetch and them save. If you dont know upfront which items size you are working with and want to have things like 'continue interrupted download' then you should probably save things as they are coming from the network.
I'm using KDE, and I'm toying with the idea of hacking the code for Dolphin File Manager (and potentially Konqueror if necessary) to get context-sensitive drag and drop behaviour (i.e. files are moved within the same partition, or copied if they're moved across partitions or the source is read only).
To do this, I think I'd need to find out the containing partition of the source and destination (easy enough on Windows using the drive letter, but on Linux, as mount points can be almost anywhere, it can't be reliably derived from the file path), and compare them.
Does anyone know how I can find out the partition that contains a given file?
It must be possible - I know Nautilus provides this sort of behaviour, but I'm not familiar enough with GTK to track down the appropriate section in the source code to see how its done...
Qt doesn't provide API for this. For POSIX, have a look at stat.
For KDE, you can use KIO::stat() to get mostly the same info as POSIX' stat function but asynchronously.
The device id should be in the field UDS_DEVICE_ID of the result.
I have been given a set of COBOL DAT, IDX and KEY files and I need to read the data in them and export it into Access, XLS, CSV, etc. I do not know the version, vendor of the COBOL code as I only have the windows executable that created the files.
I have tried Easysoft and Parkway ODBC drivers but I have not been successful in reading the data from the files.
I do not have access to the source code as the company that was distributing this product shut down.
I have successfully read some of the dat files using http://www.cobolproducts.com/datafile just now which I came to know through another forum. Most probably I will work with them to help me read the rest of the files that I am having an issue with.
A few possibilities.
1/ See if you can find the names of the people that worked for the company. They may be helpful.
2/ Open the DAT file in a text editor. The data may be decodable from that. If the basic format can be discerned, quick'n'dirty code can be written to extract it.
3/ Open up the executable in an editor, there may be strings in there that indicate which compiler was used, then you can search for info on its file formats. If it's a DOS application, there's a good chance it was either Microsoft or Fujitsu COBOL.
4/ Consider placing job requests on work sites like elance or rentacoder; I don't think there's a cost if the work can't be done successfully.
5/ Hire someone to examine it and advise on the likelihood of recovery.
6/ Get a screen dump of the record contents for every active record and re-construct it from that.
Some of these are pretty hard so your mileage may vary.
Good luck.
I have read COBOL DAT files only with FD, when I do not have the FD, I open the file in a Text Editor, and try to guess the columns, and try again, until I have this working, the big problem with this approach is when the DAT file have COMP columns, that can be any kind of COMP type, but with a litthe patience I cold get this done.
I had tryed Parkway ODBC, but without success.
for anyone going through this journey, I found this in sourceforge: Cobol and RPG data reader and converter
http://sourceforge.net/projects/cobol2j/
Im about to try it, sounds kind of promising
Ok, so I'm an idiot.
So I was working on a regex that took way to long to craft. After perfecting it, I upgraded my work machine with a blazing fast hard drive and realized that I never saved the regex anywhere and simply used RegexBuddy's autosave to store it. Dumb dumb dumb.
I sent a copy of the regex to a coworker but now he can't find it (or the record of our communication). My best hope of finding the regex is to find it in RegexBuddy on the old hard drive. RegexBuddy automatically saves whatever you were working on each time you close it. I've done some preliminary searches to try to determine where it actually saves that working data but I'm having no success.
This question is the result of my dumb behavior but I thought it was a good chance to finally ask a question here.
On my XP box, it was in the registry here:
HKEY_CURRENT_USER\Software\JGsoft\RegexBuddy3\History
There were two REG_BINARY keys called Action0 and Action1 that had hex data containing my two regexes from the history.
The test data that I was testing the regex against was here:
C:\Documents and Settings\<username>\Application Data\JGsoft\RegexBuddy 3
It depends on the OS, of cause, but on Windows I would guess the application data directory. I can't remember the path on xp but on vista it's something like this:
C:\Users\ user name \AppData\
And then it would probably be here:
C:\Users\ user name \AppData\roaming