aspose file tools
The moose likes Java in General and the fly likes Writing bytes to a device (disk) Big Moose Saloon
  Search | Java FAQ | Recent Topics
Register / Login


Win a copy of The Mikado Method this week in the Agile and other Processes forum!
JavaRanch » Java Forums » Java » Java in General
Reply Bookmark "Writing bytes to a device (disk)" Watch "Writing bytes to a device (disk)" New topic
Author

Writing bytes to a device (disk)

Michael Kato
Greenhorn

Joined: Aug 06, 2010
Posts: 12
I've read/written bytes to files for several projects but I'm wondering if I can write bytes directly to a disk. I need to write a byte pattern over an entire disk. Is there some way I would just access it using the File class or is it more involved?

Any guidance is appreciated.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 16483
    
    2

You can't do that in Java. That ability is completely opposed to Java's design as a secure language.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19216

You possibly could do it with JNI, but it will involve a lot of low, low level programming. You may be able to do it in C, but you may have to go even lower - to assembly language.


SCJP 1.4 - SCJP 6 - SCWCD 5
How To Ask Questions How To Answer Questions
Michael Kato
Greenhorn

Joined: Aug 06, 2010
Posts: 12
Ok, that's what I was afraid of. With JNI you lose Java's portability since you're using some native code, right?
I kind of doubt that assembly would be required. I'll look into other possibilities.

Thanks for the input and if anyone else has any ideas definitely let me have it.
Jesper de Jong
Java Cowboy
Bartender

Joined: Aug 16, 2005
Posts: 12911
    
    3

Yes, you would lose portability, JNI is the Java Native Interface - a way to call operating system specific code from a Java program.

You would not need to program in assembly language for this, but Java is not very well suited for very low-level things like this.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19216

Jesper de Jong wrote:You would not need to program in assembly language for this

I'm still not sure it's not needed. Not for JNI, no, but accessing drives without using the file system is very low level. I'm not sure plain old C is enough for it, you may need to go lower. And then you essentially get to assembly code.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 16687
    
  19

Rob Prime wrote:
I'm still not sure it's not needed. Not for JNI, no, but accessing drives without using the file system is very low level. I'm not sure plain old C is enough for it, you may need to go lower. And then you essentially get to assembly code.


Assembly should not be necessary -- there are c libs that does sector read/writes. On unix, it's possible to do this from Java itself -- assuming that you have permission to read/write to the device files in the "/dev" directory.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Martin Vajsar
Bartender

Joined: Aug 22, 2010
Posts: 2329
    
    2

Rob Prime wrote:
I'm still not sure (assembler) is not needed. Not for JNI, no, but accessing drives without using the file system is very low level. I'm not sure plain old C is enough for it, you may need to go lower. And then you essentially get to assembly code.

If I remember correctly, it is possible to access HW ports with plain old C. But its years I have been so close to the hardware.

However, modern disks require a driver. At least SCSI, IDE and SATA disks have different interfaces, and I assume you'd need different controlling sequences. Moreover, operating systems usually don't allow applications to access hardware ports directly, you usually need a kernel mode driver for this. So to do something like this, one would probably have to call operating system driver's functions (like format). That should be doable with C, but definitely admin rights would be needed.

For a task like this I'd choose a special utility usually provided by HDD manufacturer. Otherwise it cannot be guaranteed that the data were really overwritten precluding any possibility of their reconstruction, which seems to be the goal.
Michael Kato
Greenhorn

Joined: Aug 06, 2010
Posts: 12
For a task like this I'd choose a special utility usually provided by HDD manufacturer. Otherwise it cannot be guaranteed that the data were really overwritten precluding any possibility of their reconstruction, which seems to be the goal.

No that's not really it. Actually the goal is to write a byte pattern to the entire disk. The plan is for a disk with the pattern to be overwritten with other data sequentially (with an unrelated tool), and then I'd be able to check for any holes by searching for the byte pattern. I'd want the solution to work on any type of drive. The data would really have to be overwritten like you say though since the pattern needs to be there for this purpose.

On unix, it's possible to do this from Java itself -- assuming that you have permission to read/write to the device files in the "/dev" directory.

Could you explain this more? I thought I read this before. This might actually be desirable, if it's going to be a platform specific solution anyway (I choose Linux). Can the device be written to completely? I guess I don't need to kill the MBR and such for my purposes which the OS might not give permission to do, right.

Thanks for your responses and getting me a feel for this.
Michael Kato
Greenhorn

Joined: Aug 06, 2010
Posts: 12
Oh I also looked into dd and its relatives. It seems dcfldd has the pattern option I need, but a custom solution would allow more power and flexibility. Plus dd is way to slow, not sure why. My programs have way more throughput than dd.

I know those are open source. Maybe I'd look into that, but Java would be nicer plus I already have experience doing what I need to do (wouldn't be that hard) just with files instead of devices.

Keep shooting!
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12268
    
    1
Any approach based on files will necessarily NOT be able to write the entire disk since the operating system will have to keep file bookkeeping data on the disk somewhere.

Bill

Java Resources at www.wbrogden.com
Martin Vajsar
Bartender

Joined: Aug 22, 2010
Posts: 2329
    
    2

Michael Kato wrote:I guess I don't need to kill the MBR and such for my purposes which the OS might not give permission to do, right.

If you manage to write to physical sectors on the disk, the OS is already out of the way. No one will stop you from overwriting the MBR, if that is what you order the disk to do.

Preserving MBR is also of little value in the scenario you've presented. There might be several partitions on the disk and unless you compute their physical positions (which is normally the job of operating system drivers that you're now going around) to spare them, they'll get overwritten too. Also, even empty partition has its structure (just a few sectors probably, but anyway) and if you don't avoid them, the partitions will be unusable.

All in all, any HDD you give this treat will probably have all data and structure lost and will have to be repartitioned and reformatted. Make sure your users will be very, very clear what HDD they are operating on.
Michael Kato
Greenhorn

Joined: Aug 06, 2010
Posts: 12
Any approach based on files will necessarily NOT be able to write the entire disk since the operating system will have to keep file bookkeeping data on the disk somewhere.

All right. If so, then would that unharmed bookeeping data be in predictable spots? Would it prevent my purpose?

If you manage to write to physical sectors on the disk, the OS is already out of the way. No one will stop you from overwriting the MBR, if that is what you order the disk to do.
Preserving MBR is also of little value in the scenario you've presented.

Yeah if I overwrite the MBR that's even cleaner so I'm not trying to preserve it certainly. I just want to cover as much of the disk with the pattern as I can.

All in all, any HDD you give this treat will probably have all data and structure lost and will have to be repartitioned and reformatted. Make sure your users will be very, very clear what HDD they are operating on.

That's ok this type of thing is a regular activity so the users have no problem with this.

I just want to see if I can do this. Assuming it's done in Linux, and I have whatever permission needed, can I write a byte pattern to a disk device (as a File) with my Java program and mostly cover it... enough so for the rest of the plan to be effective?

What do you think I'd get if I made a program right now to open up a "blank" disk in /dev as a File and write the pattern until it's full? (lol, no "why don't you try it and find out" responses please, I will try if needed)

Thanks for responses!
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19216

For this kind of thing I would create a virtual machine. Give it two disks, so you can wipe one all you want.
 
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to run our stuff on 16 servers instead of 3.
 
subject: Writing bytes to a device (disk)
 
Similar Threads
Client Server File transfer
progressbar in real time and streams
FTP Uploading
java mail excel attachment problem
Writing Image Bytes on Response Stream