Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I recently did something stupid on my dual-boot laptop, where I compressed the entire volume to make room for a Linux partition. For some reason, Windows let me compress C:\ntldr. Now I need to get it uncompressed in order for Windows to boot.

Here are some of the operating restrictions I have:

  • I do not have access to the BIOS.
  • I cannot boot from CD/USB/floppy. (I installed Linux through PXE)
  • It does not have network access.

Is there were some way to specify that the ntfs-3g driver shouldn't compress files even if it thinks it should (if the directory is compressed) when mounting the volume?

Or, is there a way to modify the attributes of a directory using ntfsprogs?

share|improve this question
add comment

4 Answers

You can't boot from an external drive so USB/CD repair is out...can't get network access...um...I don't know of anything that can outrightly fix it from Linux. NTFS support for anything other than reading and writing (and relatively speaking even write support was dodgy until fairly recently) is scant, as the attitude from the Linux community is that NTFS is for native Windows.

I was going to suggest using VMWare or VirtualBox to boot Windows in a VM and give it access to the partition; that could fix it, but you said you didn't have network access to install a VM hypervisor.

If you absolutely need the data, the only thing I could suggest is to physically remove the drive and put it into an adapter to allow it to work as an external USB drive to a machine running Windows and decompress it/run a repair from there. Otherwise, restore from backup...

share|improve this answer
add comment

(I installed Linux through PXE)

It does not have network access.

I'm confused, but ok..

The key to getting linux installed on any machine is

  1. that most machines have some form of boot selection
  2. the boot process is not tied to the OS (so that you can boot something other than windows)

Given that all of the "normal" boot vectors don't appear to be available to you, I'd say, pull the drive at this point and attach it to another machine.


Follow-up based on comment(s):

So let's review:

  1. External booting is out. This kills any chance of using a USB stick, CD repair, live boot CD, etc.
  2. Removal of the HDD is possible but highly undesirable
  3. PXE booting is possible under certain circumstances

So it looks like PXE (the same method you used to get the dual-boot up and running) is going to be your easiest bet. Can you find out what the address is for the PXE server you were using? If so, you might be able to arrange a bit of a hack...you'll need a computer that can act as a PXE server and a wired hub that isn't attached to any other network.

  1. Set up your PXE server environment
  2. configure the PXE server to have the same address as the one expected by the BIOS
  3. boot the laptop via PXE
  4. supply the laptop with the environment of your choosing

I'm not sure if you can live-boot a windows CD in this manner (I have only done old-style DHCP/BOOTP/TFTP boots, not PXE), but if you could, you might be able to access the repair console, which would be your best bet. Your second option would be to get a linux live-boot CD into the laptop, and try to repair it from there, although I suspect you'll have limited success. As a last-ditch effort, you can always migrate the data onto another device (now that the laptop is functional again).

share|improve this answer
    
I meant to say it doesn't have Internet access; I managed to get it hooked up to a wired hub and that's how I used PXE, but through some wonky BIOS settings, it won't allow gateways that aren't the PXE server, nor will it allow the wireless if the system acknowledges the existence of the wired NIC. It's a laptop, and I don't own it. If I open it up, I could get fined upwards of $800. They don't care about the software portion, though. –  amphetamachine May 2 '10 at 21:09
add comment
up vote 0 down vote accepted

Okay, I think I've solved it. The problem lies in the ntfs-3g driver; it tries too hard to predict what the user wants.

I solved the problem by mounting the volume on /mnt/windows using the ntfs-3g driver, then copying the ntldr file out of the volume.

# mount -t ntfs-3g /dev/sda1 /mnt/windows
# cp -p /mnt/windows/ntldr ~/ntldr
# mv /mnt/windows/ntldr{,.bak}
# umount /mnt/windows

Then, using ntfsprogs' ntfscp, I re-copied the file back into the file system:

# ntfscp -f /dev/sda1 ~/ntldr ntldr

Then, when I did an ntfsinfo on it it no longer had the compressed attribute present.

share|improve this answer
add comment

The problem lies in the ntfs-3g driver; it tries too hard to predict what the user wants.

As far as I can see, ntfs-3g did what the user wanted. It compresses the file because the user set the directory compressed.

The problem actually lies in ntfcp which doesn't follow the NTFS specification.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.