Is it safe to disconnect a SATA disk during sleep?

Is it safe to disconnect a SATA disk during sleep Windows 7? Is the disk powered off when the computer successfully have entered sleep mode? This is not my system disk, it's just a spinning disk for my photos.

Is it safe to just yank an external hard drive if you know nothing is writing to it?

Yes, I know somewhat about the possibility of data corruption if there was data that hadn't been all written to it.

But I just saw this:

Note:If u remove HDD(not USB sticks) without safely removing it,its not healthy and will affect life.

So, if nothing is actually writing to it, could there actually be any harm caused by not safely removing or unmounting it before disconnecting it?

btrfs restore specific directory

I have a damaged btrfs filesystem, and I am using btrfs restore to restore it. It seems to work.

The problem is that the damaged filesystem is quite huge, and I need only to restore just one directory. I see from the man page the option

-d directory

but the wiki I see -d: ???. Do you how to use this flag and if it can help me?

Linux media box/mail server suffering filesystem/RAID errors, kernel panics

In the past week, the mini-ITX machine I built myself to serve mail and Samba shares has kernel panicked twice with filesystem-related stuff. Last night I noticed integrity errors when streaming a movie to my set-top client (video artifacts), so I started poking around.

Both the internal hard drive and the external hard drive use linux software RAID and on either mirror, if I do an md5sum on a fairly large file like a video, and do it repeatedly, I get a different checksum each time (I should note that one is ext4, the other is JFS). I booted off a USB stick into recovery mode, same thing happening. I haven't tried reading off the external mirror on another computer, but I did mount one of the constituent disks and it seemed fine, at least it was giving consistent md5sums there.

So, filesystem's been ruled out (it's happening on both ext4 and JFS), hard drives are probably out (it would be an incredibly coincidence), SATA controllers are probably out seeing as it's happening on two completely independent controllers, a corrupted kernel module or something is out seeing as it's doing it even when booting off of the rescue disk.

The fact this is happening to two separate sets of drives, controlled by two separate SATA controllers, running two different filesystems, and the behaviour is preserved when booting two different kernels makes me think the only plausible option is that there is something horribly wrong with the motherboard. This motherboard was already an RMA replacement from a company I don't particularly trust (Zotac), so it would be less surprising than usual.

This is Ubuntu Server 10.04, by the way, 64-bit, on a Zotac IONITX-C (I think) motherboard with an Atom N230.

Does anyone have any other ideas, diagnostics I should perform, etc.?

EDIT: Two things I forgot to mention: when I booted off the USB key I did run fsck on both md devices quite a bit.

This is what the panics look like:

I've tried searching Google a few of these without much success, but I think it's more likely the hardware to blame anyway; I just don't know which specific piece of hardware.

EDIT 2: Just ran memtest86, and not a single test is passing. The least significant 2 bytes of the test pattern seem to be always read back wrong. Still not sure whether it's RAM or chipset, and I don't have an extra stick of RAM to test with.

Does flash-memory integrity depend on system resources while reading/writing (like CDs/DVDs)?

Question

I’m really concerned that flash-memory is just not reliable as a storage for irreplaceable files. Does anybody know if the integrity (corruptibility) of flash-memory (flash-drives, memory-cards—SSDs?) depend on the system and its resource load?

That is, if you are writing (or reading?) to a USB flash-drive or memory-card while the system is under a load (something in the background running the CPU at 100%, using up a lot of memory, or causing the hard-drive to thrash a lot), could it cause the data written to or read from the flash device to be corrupt?

Background

I have recently gotten two brand-new flash-drives (a Kingston memory-card and a Kingston USB-drive). I copied a folder with a lot of files to both of them (at the same time), and when I compared them to the source (and each other), I found that some files were shown as being different. Some of them were false-positives and re-comparing them made them go away (they were suddenly identical again), while some were permanently corrupt (some had 8 bytes in a row different, some had several dozen in a row). After copying the corrupt files again and comparing them, they showed as identical.

Observations

It doesn’t seem to be system related (e.g., bad memory) because I’ve seen it happen on a laptop and desktop. Nor is it OS dependent; it’s happened on 64-bit 7 and 32-bit XP. It doesn’t seem to be related to the USB port or memory-card reader (again, different systems). It is not even the device itself (I’ve seen it happen on SanDisk and Kingston memory-cards and USB-drives). Unfortunately I can’t do any tests because while it’s not fully intermittent, it is random (I may be able to force it to happen, but would be unable to control the results).

The only factor that seems to be even slightly consistent when it happens seems to be the resource-load of the system that is reading or writing to the flash-memory. It’s almost as though the device cannot get the data fast enough—as though flash-drives and cards are sooo fast (¬_¬)—so it writes junk and moves on, much like how burning a CD or DVD requires a constant, steady stream of data without interruption to avoid corrupting the disc (even with a built-in buffer).

Is that really how flash-memory drives work? If so, why? Why are they not like hard-drives that simply take longer to perform the disk operation? Surely in this day and age, systems are designed to be dynamic and use variables and error-handling instead of expecting all operations to complete in an arbitrary prescribed amount of time and fail if it they are not.

Repairing a corrupt exFat file system

Long story short : I messed up my GPT and went on to try to fix it without asking anyone, just searching around. Didn't turn out too well.

Right now all I'm concerned about is a 500GB that I formatted as exFat partition with some important files. But on my journey to fix, I may have used the 'fdisk' command on a GParted Live CD I have (couldn't get on any OS) and switched it to ext2. Now I can't get access to it, doesn't show up on Windows or Mac. Only on the partition table as ext2.

I have got access to most of my files through recovery softwares but they cannot recover with the originial directory or file names, which would be a pain to fix.

I want to know if there is a way to change back the file system to exFat without having to format it.

Thanks in advance.

EDIT:

This is how my partitions look like right.

MicroSD card getting corrupted for no good reason

I recently bought an MicroSD card online. It's a Sandisk 16GB class 2.

However, it has a nasty problem. Every time I fill it with my data, the fat tables get corrupted. I've tried reformatting it, blanking it, doesn't seem to solve the problem. I have tried windows and linux (ubuntu), both have the problem. I've used my usb microsd readers, and even tried putting it in my phone and putting data on it from there. All have this problem.

Now the really odd thing is, besides the corrupted file tables, no programs can find anything wrong with the hardware. I've tried both chkdisk and "badblocks -w", neither give any type of error.

Now I don't know if the actual data gets corrupted, or if its just filesystem tables. What happens is that one or more folders start showing a load of chinese-charred (random UTF8 symbols I suppose) folders and files, and it is impossible to do anything with those. All the other data (outside of the corrupted folders) seems fine. I've tried to test it, and the problem doesn't seem to show up until I fill the disk upto about 3~4GB. After that I can still access the data. But as soon as I eject/safely remove/unmount it, the bad things happen somehow. Next time I plug it in, the folders I most recently wrote to (but sometimes also the folders I wrote the time before last time to) are all gibberish.

Does anybody have any clue what might be going on here?

EDIT: It seems I can't even put ext3 or ext4 on it, they both complain about a corrupted journal. Gheh, guess something is really broken here.

Ubuntu and Windows 8 shared partition gets corrupted

I have a dual boot (Ubuntu 12.04 and Windows 8) system. Both systems have access to an NTFS "DATA" partition which contains all my images, documents, music and some application data like Chrome and Thunderbird Profiles which used by both OS.

Everything was working fine in my Dual boot Ubuntu/Windows 7, but after updating to Windows 8 I am having a lot of troubles. First, sometimes, I add some files from Ubuntu into my DATA partition but they don't show up in Windows. Sometimes, I can't even use the DATA partition from Windows. When I try to save a file it gives an error "The directory or file is corrupted or unreadable". I need to run checkdisk to fix it but after some time, same error appears.

Before upgrading to Windows 8 I also installed a new hard drive and copied the old data using clonezilla (full disk clone).

Here is the log of my last chkdisk:

Chkdsk was executed in read/write mode.  

Checking file system on D:
Volume dismounted.  All opened handles to this volume are now invalid.
Volume label is DATA.

CHKDSK is verifying files (stage 1 of 3)...
Deleted corrupt attribute list entry
with type code 128 in file 67963.
Unable to find child frs 0x12a3f with sequence number 0x15.
The attribute of type 0x80 and instance tag 0x2 in file 0x1097b
has allocated length of 0x560000 instead of 0x427000.
Deleted corrupt attribute list entry
with type code 128 in file 67963.
Unable to locate attribute with instance tag 0x2 and segment
reference 0x1e00000001097b.  The expected attribute type is 0x80.
Deleting corrupt attribute record (128, "")
from file record segment 67963.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x2431b2 for possibly 0x20 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x1791e is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 96542.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0x6bc7 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x17e83 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 97923.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0x1f7cec for possibly 0x5 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0x17eaf is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 97967.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x441bd7f for possibly 0x9 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x32085 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 204933.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4457850 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x320be is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 204990.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4859249 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3726b is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225899.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x485d309 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3726c is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225900.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x48a47de for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37286 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225926.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x48ac80b for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37287 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225927.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x48ae7ef for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37288 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225928.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x48af7f8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3728a is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225930.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x48c39b6 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37292 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 225938.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x495d37a for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x372d7 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226007.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4d0bd38 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x372dc is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226012.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4c2d9bc for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x372ed is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226029.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4a4c1c3 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37354 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226132.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4a8e639 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37376 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226166.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4a8f6eb for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37379 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226169.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4ae1aa8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37391 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226193.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4b00d45 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x37396 is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226198.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4b02d50 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3739c is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226204.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4b3407a for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x373a8 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226216.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4bd8a1b for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x373db is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226267.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4bd9a28 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x373dd is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226269.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4c2fb24 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x373f3 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226291.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cb67e9 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37424 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226340.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cba829 for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37425 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226341.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cbe868 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37427 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226343.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cbf878 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37428 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226344.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cc58d8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3742a is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226346.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4ccc943 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3742b is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226347.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cd199b for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3742d is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226349.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cd29a8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3742f is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226351.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cd39b8 for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37430 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226352.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cd49c8 for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37432 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226354.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cd9a16 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37435 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226357.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cdca46 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37436 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226358.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4ce0a78 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37437 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226359.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4ce6ad9 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3743a is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226362.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cebb28 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3743b is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226363.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4ceeb67 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3743d is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226365.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cf4bc6 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x3743e is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226366.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cfbc3a for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37440 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226368.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4cfcc48 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37442 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226370.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4d02ca9 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37443 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226371.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4d06ce8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37444 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226372.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4d9a608 for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x37449 is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226377.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4d844ab for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x3744b is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226379.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4d6c32b for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x3744c is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226380.
Attribute record of type 0xa0 and instance tag 0x5 is cross linked
starting at 0x4d2af25 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0xa0 and instance tag 0x5
in file 0x3744e is already in use.
Deleting corrupt attribute record (160, $I30)
from file record segment 226382.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4d0fd78 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x37451 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 226385.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x4d16ef8 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x8

Can anyone help? Thank you

PC won't boot from flash drive after computer hibernated (grub on hdd corrupt too)

I had 3 OS installed: Windows 7 , Fedora 17 and Mageia 2 in my Acer Aspire 4253 laptop.

I deleted the partition of Mageia and my grub got corrupted.
I didn't have an installation DVD of either Win7 or Fedora, so I used super grub 2 from a flash drive to boot my laptop.

Then one day when I was using Windows 7, my battery was critically low and laptop got hibernated. When I plugged in the power and restarted the press F2, f12 prompts were missing and the flash drive is not getting detected after POST.

What can I do now to boot my PC?

TrueCrypt: filesystem corruption: is it possible to lose all data at once?

I read that among various corruption risks is the filesystem corruption, that also affects TrueCrypt volumes, like any other system.I would like to know if it is possible that a corruption in some special small region can lead to lose the entire filesystem?

How can I create a file with invalid Windows timestamps?

I'd like to create a file with an invalid created/modified/accessed timestamp. To be invalid it should be a date and time before 12:00 midnight January 1, 1601 C.E. UTC

How to delete corrupt folder?

I have a folder on the desktop which is about 1.6 GB in size. When I try to open it I get a message like this:

The file or directory is corrupt or unreadable

Fortunately, I have a backup of that folder so I want to get rid of this folder. If I try to delete it, it fails to delete however I can rename the folder, move it and do whatever except deletion. I've tried various methods but could not succeed.

I am using Windows 8.1 Pro.

What to do with a USB hard drive that is not recognized by any computer

I have a USB HDD that was disconnected from a computer in an improper way. Since than, connecting this disk to any computer has almost no effect: the only thing that changes is the HDD's blue LED that turns on. The computer sees nothing. I tried this on several computer under Win XP and under Ubuntu. The HDD is Verbatim model #53001, 320GB

What can I do in order to access the data on the HDD?

Tool to repair MFT or NTFS journal on a disk which underwent failed hibernation

I've read through some of the posts related to corrupt or not working NTFS partitions, but without a proper solution for my case. Here it is: my system is

• SSD on mini PCI express (PCIe), with Windows 7 installed on it. Two partitions: one with Dell utilities (40 MB), the rest the windows installation itself (119 GB).
• HDD with 450 GB of NTFS files, and 30 GB of all the partitions that make a Ubuntu installation work (swap, system, etc.)

The boot device is Internal HDD (IRRT), the only possible one; this enables IRRT, and starts GRUB, which by pointing to some sector on the HDD can start Windows 7 on the SSD.

Now what happened:

I put my computer to sleep, and then it went to hibernation after some hours. The wireless card was physically disabled (Dell M4600). Then I started up the laptop, and before GRUB was complete, I switched on the wireless card again. Then pressed "windows" on GRUB. Then BSOD, reboot, and windows cannot find the booting partition: "needed device missing".

I have tried the Windows 7 recovery disc: can only repair the tiny bit of the Windows installation that is on the HDD, cannot see the SSD. The "repair" does nothing. Removing the hard drive to get around GRUB by force did not make the Windows DVD see the boot sector of the SSD. It was not enough of a "Windows installation".

Now, if I start to act as if I would install Windows again, Windows sees the two partitions on drive C, they are still here, in NTFS.

Then I went to Linux and tried fdisk: the partitions are still here, again. But they don't show up in Nautilus, and I cannot mount them. However, dd can recover data: if I try reading data at some random big offset (like offset 20 GB, and read 10 blocks), the blocks are indeed "data", no problem to access the drive physically, it doesn't seem to have failed completely at least. I will do a backup tomorrow then.

I tried TestDisk: boot sectors are identical and seem OK, but both MFT show as "bad", nothing more. Cannot access the files inside the file system.

On that site, I saw something about a wrong write in NTFS journaling, Need to recover corrupt NTFS partition .

Almost last post. Nothing about it on the Internet, as far as I searched.

And I suspect something about the hibernate process is not reversed, as I remember that the hibernate process changes the boot sequence a lot (or else you could move hiberfil.sys without a problem, but you can't. It needs to be in the root directory, because there is no place in the boot loader to accommodate for a folder location, or even another drive!).

So maybe both boot sectors were affected by the hibernation, and when it could not complete the process of reverting to normal boot, it stayed like this, Windows looks where the boot pointer points and does not recognize a normal Windows installation and refuses to repair it, and as Linux cannot find the MFT it cannot mount it...or maybe something different, affecting the MFT itself. I don't know... I will try CHKDSK and, after backup, fixmbr, from the Windows 7 DVD.

UPDATE: fixmbr and fixboot seem to only work from the recovery console, and I couldn't access it. From the Windows 7 DVD, I could do CHKDSK : it only said the volume was NTFS before crashing because "MFT corrupted. Will try repair. MFT Could not be repaired. Exit chkdsk".

When trying diskpart, it saw my partition on the SSD as...Raw. So, this does not correspond to what CHKDSK has seen.

Something is weird in all this: all this time, Windows did not see the first 40 MB of my SSD, which contained Dell utilities. On Windows 7 Explorer the main partition of the SSD was always C:\, and the partition of the HDD was D:\: this 40 MB partition on the SSD never appeared anywhere. But now, Windows sees this 40 MB partition, and gives it the C:\ letter. While the D:\ letter corresponds to the 119 GB partition, "Raw" format, unable to be read. I don't understand anything...

Hard Drive Caddy corrupting drives

Something very funny is going on with my External Hard drive Caddy. I am running Linux Mint 14.

I had a laptop breakdown just before Christmas, removed the drive and placed it into a 2.5" SATA caddy, verified the data was there - no read operations, removed the drive, tried to access it days later to find the ext3 filesystem was totally corrupted. I assumed that was a disk issue.

I recently used the same caddy with an NTFS disk, data was fine, unmounted the disk, checked it days later, disk is entirely unreadable

So just now I checked it with a 3rd, old hard drive. Read the data, all fine, unmounted, reinserted, disk unmountable.

Any ideas what on Earth is going on, and more importantly how I can get the data back? it must still be there