Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to resize a NTFS partition in a disk for which I have an image (dumped with dd).

I mounted it through the loop device on linux:

# losetup -o 32256 /dev/loop0 disk.img # I got the offset from looking at fdisk's output
# mount /tmp/t /dev/loop0
# ls /tmp/t
[content of NTFS partition shows correctly]
# umount /tmp/t
# gparted /dev/loop0

gparted shows me the disk correctly; it just contains one large NTFS partition I want to shrink.

I have it had it running for one hour now.

Question: will this work? There is lots of disk access but the timestamp and size of the underlying file disk.img remain unchanged.

share|improve this question
any idea how well the disk was defragged before you did the dd dump? (alliteration ftw!) shrinking the partition can involve moving data away from the back of the "disk", which could explain why it's taking so long. how big is the "disk" and how full is the filesystem? – quack quixote Feb 1 '10 at 21:55
up vote 2 down vote accepted

Yes, loop devices are indistinguishable from 'normal' block devices for higher layer applications (like gparted). Loop device access doesn't change timestamp of mounted file: it is a bug.

Also, while kernel won't create partition subdevices, you can make them with kpartx if you need so (just in case).

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .