Are there any libraries or Windows API functions that enable writing to the sectors of a CD-R directly? I am able to read sectors from the drive using the ReadFile function provided by the Windows API but using the WriteFile function on the drive seems only to mark the disk as in-use (after executing a program in which WriteFile is used on a CD-R, I am unable to burn files onto the disk or eject it until I restart the system). When I restart the system, there is no data on the disk. Opening the disk drive for write access and calling the WriteFile function with the disk drive handle produces no system errors.
I don't know easy way, but there is a set of SCSI commands, that burning software use.
Under windows you has to get ASPI library to obtain SendASPI32Command Free one and find somewhere a description of Multi-Media Commands. Start from www.t10.org, they sell it, but working draft can be found for free.
and then start there and then look for example of MMC commands using in cdrecord sources.
It can be done but hard though.
Access to the write process is probably restricted to allow compatibility with the drag-and-drop writing that can be done in the Explorer.
You could use an alternative approach and write to an ISO image and then dump that to the CD when it is complete.
Related
There is a program (program A), that uses some specific file in some folder. Normally that file is on the hard disk.
I need to write a program (program B) that can create such file, but this file should be physically in RAM, not on HDD. So if you unplug HDD, you could not find the file.
I also have no access to program A code. But I want A to interpreting that file as a normal file.
Is it possible in Windows to do something like that?
The only way to have a file that is only in memory is to use a RAM-drive. You can find free RAM-drives and probably some open source implementations but they do require a kernel driver. NTFS mount points will allow you to mount this drive as a subfolder on drive C: if that is a requirement.
From a programming point of view, the only thing program B would be able to do is to set the delete-on-close flag after program A has opened the file. Depending on how A uses the file, you might be able to just delete the file, and if not, B would have to call SetFileInformationByHandle(FileDispositionInfo, ...) on the file handle but this will only work if program A opens the file with the share flags set to allow delete. I have never tested this so I'm not 100% sure it would work if power was lost. NTFS does have journaling that makes sure the filesystem state is correct but I'm not sure if it applies to the delete flag.
I had a usb flash drive which had data and was using FAT32 file table, till yesterday!
I had been using it only in Windows. Now when I plugin the usb flash drive, Windows XP reports the file system as RAW and trying to access the drive asks to format the drive. I desperately need to get some data out from there (the backup is a few days old).
I've already used a dozen of programs under windows that claim to read RAW data, but none has worked yet. Is there any script, utility or program under FreeBSD or Windows that will aid me in getting that data back? If I plugin the usb drive to my FreeBSD box it only appears as /dev/da0, so I cannot mount it.
Apologies if I am not making sense, but is there any light at the end of the tunnel?
You can use dd to make a raw copy:
dd if=/device of=target_file
After that, you may want to google for "data carving", and use a program such as foremost.
When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence
I created a backup disk image of my disk yesterday and the software told me to close all Windows programs to make sure the process finishes successfully.
I did that, but I was wondering what happens when some program does write to the disk nevertheless during the process. Windows 7 is a complex system and surely various log files and such are written continuously (the disk has one partition which contains the Windows install too). How does the backup software handle it when the disk content is changed during image creation?
What is the algorithm in this case?
Snapshotting, or 'Shadow Copy' as Microsoft calls it, see Shadow Copy on wikipedia
I wrote a disk utility that allowed you to erase whole physical drives. it uses the windows file api, calling :
destFile = CreateFile("\\\\.\\PhysicalDrive1",
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING,createflags, NULL);
and then just calling WriteFile, and making sure you write in multiples of sectors, i.e. 512 bytes.
this worked fine in the past, on XP, and even on the Win7 RC, all you have to do is make sure you are running it as an administrator.
but now I have retail Win7 professional, it doesn't work anymore! the drives still open fine for writing, but calling WriteFile on the successfully opened Drive now fails!
does anyone know why this might be? could it have something to do with opening it with shared flags? this is always what I have done before, and its worked. could it be that something is now sharing the drive? blocking the writes? is there some way to properly "unmount" a drive, or at least the partitions on it so that I would have exclusive access to it?
some other tools that used to work don't any more either, but some do, like the WD Diagnostic's erase functionality. and after it has erased the drive, my tool then works on it too! leading me to believe there is some "unmount" process I need to be doing to the drive first, to free up permission to write to it.
Any ideas?
Update:
the error code returned from WriteFile is '5', ERROR_ACCESS_DENIED
but again, if I 'erase' the drive first using WD Diag, I can then access and write to the drive fine. when I initialize the drive again, and give it a partition, I go back to getting the ERROR_ACCESS_DENIED error.
This is almost certainly related to preventing the attack found against driver signing by changing sectors in the page file. It will prevent writing to the areas of the disk containing partitions.
See http://msdn.microsoft.com/en-us/library/aa365747%28VS.85%29.aspx and look at the information starting with the text "If you write directly to a volume that has a mounted file system", basically you have to lock the disk's volumes in order to write to their sectors.