1

I have recently started using Fedora on my laptop. I've set it up so that it sits on a roughly 20GB encrypted partition and most of the Home folders (Downloads, Documents, Pictures) are symlinked to there Windows equivalents. It has worked well usually, at least until I start saving files in those folders

While I'm in Fedora I can save all my files to the Windows partition and view them just fine. However when I boot into Windows 7, half the time the files don't even show up. Running chkdsk shows lots of errors and proceeds to delete most of the files I created in Linux

If useful this is the full chkdsk log from the last run where I lost a lot of downloads among other files (its very verbose since I grabbed it from the Event Log)

Checking file system on C:
The type of the file system is NTFS.
Volume label is Windows_7.


One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.                         

CHKDSK is verifying files (stage 1 of 3)...
Cleaning up instance tags for file 0xf9aa.
Cleaning up instance tags for file 0xf9c5.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x143df90 for possibly 0xf18 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362a8 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221864.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x16c94a0 for possibly 0x104 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362ad is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221869.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x14376bc for possibly 0xffc clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362b4 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221876.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x1f936d0 for possibly 0x354 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362c3 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221891.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2375bc0 for possibly 0x9a9 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362c5 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221893.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x24eccb0 for possibly 0xb4 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362c6 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221894.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x22f9078 for possibly 0x134 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362c9 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221897.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x1f90048 for possibly 0x688 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362ca is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221898.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2337638 for possibly 0xa78 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362cf is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221903.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2520698 for possibly 0x90 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d0 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221904.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2374bc1 for possibly 0x70 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d1 is already in use.
Deleted corrupt attribute list entry
with type code 128 in file 221905.
Unable to locate attribute with instance tag 0x2 and segment
reference 0x10000000362d1.  The expected attribute type is 0x80.
Deleting corrupt attribute record (128, "")
from file record segment 221905.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x232ebe0 for possibly 0xb4 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d2 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221906.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x247bc88 for possibly 0x74 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d3 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221907.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x230a0d8 for possibly 0x17c clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d4 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221908.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x232abdf for possibly 0x800 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d6 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221910.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2341630 for possibly 0x400 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d7 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221911.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2321580 for possibly 0x1e1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362d8 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221912.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0x2342630 for possibly 0xc00 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362db is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221915.
Attribute record of type 0x80 and instance tag 0x2 is cross linked
starting at 0xa2a46a for possibly 0x5d clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x2
in file 0x362e5 is already in use.
Deleting corrupt attribute record (128, "")
from file record segment 221925.
  221952 file records processed.                                          File verification completed.
  589 large file records processed.                                      0 bad file records processed.                                        2 EA records processed.                                              44 reparse records processed.                                       CHKDSK is verifying indexes (stage 2 of 3)...
Deleted invalid filename Screenshot from 2012-07-08 18:29:56.png (6790) in directory 100707.
The NTFS file name attribute in file 0x1a86 is incorrect.
53 00 63 00 72 00 65 00 65 00 6e 00 73 00 68 00  S.c.r.e.e.n.s.h.
6f 00 74 00 20 00 66 00 72 00 6f 00 6d 00 20 00  o.t. .f.r.o.m. .
32 00 30 00 31 00 32 00 2d 00 30 00 37 00 2d 00  2.0.1.2.-.0.7.-.
30 00 38 00 20 00 31 00 38 00 3a 00 32 00 39 00  0.8. .1.8.:.2.9.
3a 00 35 00 36 00 2e 00 70 00 6e 00 67 00 67 00  :.5.6...p.n.g.g.
64 00 64 00 73 00 e3 db 9f 64 df 00 00 80 16 00  d.d.s....d......
File 6790 has been orphaned since all its filenames were invalid
Windows will recover the file in the orphan recovery phase.
Correcting minor file name errors in file 6790.
Deleted invalid filename Screenshot from 2012-06-19 18:51:56.png (95798) in directory 100707.
The NTFS file name attribute in file 0x17636 is incorrect.
53 00 63 00 72 00 65 00 65 00 6e 00 73 00 68 00  S.c.r.e.e.n.s.h.
6f 00 74 00 20 00 66 00 72 00 6f 00 6d 00 20 00  o.t. .f.r.o.m. .
32 00 30 00 31 00 32 00 2d 00 30 00 36 00 2d 00  2.0.1.2.-.0.6.-.
31 00 39 00 20 00 31 00 38 00 3a 00 35 00 31 00  1.9. .1.8.:.5.1.
3a 00 35 00 36 00 2e 00 70 00 6e 00 67 00 10 00  :.5.6...p.n.g...
00 00 02 00 00 00 99 db 9f 64 df 00 00 80 20 00  .........d.... .
File 95798 has been orphaned since all its filenames were invalid
Windows will recover the file in the orphan recovery phase.
Correcting minor file name errors in file 95798.
An index entry of index $I30 in file 0xfda2 points to file 0x3633b
which is beyond the MFT.
Deleting index entry example2.mkv.trashinfo in index $I30 of file 64930.
An index entry of index $I30 in file 0xfda2 points to file 0x3633d
which is beyond the MFT.
Deleting index entry temp.asf.trashinfo in index $I30 of file 64930.
Unable to locate the file name attribute of index entry vlc-2.0.3-win32.exe
of index $I30 with parent 0xfe20 in file 0x34e10.
Deleting index entry vlc-2.0.3-win32.exe in index $I30 of file 65056.
An index entry of index $I30 in file 0x18963 points to file 0x36331
which is beyond the MFT.
Deleting index entry IMG_20120730_203055.jpg in index $I30 of file 100707.
Unable to locate the file name attribute of index entry Screenshot from 2012-06-19 18:51:56.png
of index $I30 with parent 0x18963 in file 0x17636.
Deleting index entry Screenshot from 2012-06-19 18:51:56.png in index $I30 of file 100707.
Unable to locate the file name attribute of index entry Screenshot from 2012-07-08 18:29:56.png
of index $I30 with parent 0x18963 in file 0x1a86.
Deleting index entry Screenshot from 2012-07-08 18:29:56.png in index $I30 of file 100707.
Unable to locate the file name attribute of index entry Copy of Phone Log.xlsx
of index $I30 with parent 0x18966 in file 0x8ac7.
Deleting index entry Copy of Phone Log.xlsx in index $I30 of file 100710.
Unable to locate the file name attribute of index entry COPYOF~1.XLS
of index $I30 with parent 0x18966 in file 0x8ac7.
Deleting index entry COPYOF~1.XLS in index $I30 of file 100710.
Unable to locate the file name attribute of index entry FirefoxPortable_14.0.1_English.paf.exe
of index $I30 with parent 0x18966 in file 0x10930.
Deleting index entry FirefoxPortable_14.0.1_English.paf.exe in index $I30 of file 100710.
Unable to locate the file name attribute of index entry FIREFO~1.EXE
of index $I30 with parent 0x18966 in file 0x10930.
Deleting index entry FIREFO~1.EXE in index $I30 of file 100710.
Unable to locate the file name attribute of index entry vlc-2.0.2-win32.exe
of index $I30 with parent 0x18966 in file 0xc2d.
Deleting index entry vlc-2.0.2-win32.exe in index $I30 of file 100710.
Unable to locate the file name attribute of index entry vlc-2.1.0-git-20120719-0003-win32.exe
of index $I30 with parent 0x18966 in file 0x35768.
Deleting index entry vlc-2.1.0-git-20120719-0003-win32.exe in index $I30 of file 100710.
Unable to locate the file name attribute of index entry VLC-20~1.EXE
of index $I30 with parent 0x18966 in file 0xc2d.
Deleting index entry VLC-20~1.EXE in index $I30 of file 100710.
Unable to locate the file name attribute of index entry VLC-21~1.EXE
of index $I30 with parent 0x18966 in file 0x35768.
Deleting index entry VLC-21~1.EXE in index $I30 of file 100710.
Unable to locate the file name attribute of index entry VLCPortable_2.0.2.paf.exe
of index $I30 with parent 0x18966 in file 0x8a3.
Deleting index entry VLCPortable_2.0.2.paf.exe in index $I30 of file 100710.
Unable to locate the file name attribute of index entry VLCPOR~1.EXE
of index $I30 with parent 0x18966 in file 0x8a3.
Deleting index entry VLCPOR~1.EXE in index $I30 of file 100710.
Unable to locate the file name attribute of index entry Weekly Schedule.pdf
of index $I30 with parent 0x18966 in file 0x80d.
Deleting index entry Weekly Schedule.pdf in index $I30 of file 100710.
Unable to locate the file name attribute of index entry WEEKLY~1.PDF
of index $I30 with parent 0x18966 in file 0x80d.
Deleting index entry WEEKLY~1.PDF in index $I30 of file 100710.
Index entry [Z-Z] Claymore 1-26 DVDRip (Dual Audio) of index $I30 in file 0x18966 points to unused file 0x362a2.
Deleting index entry [Z-Z] Claymore 1-26 DVDRip (Dual Audio) in index $I30 of file 100710.
  319972 index entries processed.                                         Index verification completed.
CHKDSK is scanning unindexed files for reconnect to their original directory.
Recovering orphaned file [CBM] FLCL Complete (BDRip)-(Dual Audio)-(720p HD) (68323) into directory file 100710.
Recovering orphaned file Claymore(2007)DVD.H264[Eclipse] (221890) into directory file 100710.
  51 unindexed files scanned.                                         CHKDSK is recovering remaining unindexed files.
  49 unindexed files recovered.                                       CHKDSK is verifying security descriptors (stage 3 of 3)...
  221952 file SDs/SIDs processed.                                         Cleaning up 157 unused index entries from index $SII of file 0x9.
Cleaning up 157 unused index entries from index $SDH of file 0x9.
Cleaning up 157 unused security descriptors.
Security descriptor verification completed.
Inserting data attribute into file 221864.
Inserting data attribute into file 221869.
Inserting data attribute into file 221876.
Inserting data attribute into file 221891.
Inserting data attribute into file 221893.
Inserting data attribute into file 221894.
Inserting data attribute into file 221897.
Inserting data attribute into file 221898.
Inserting data attribute into file 221903.
Inserting data attribute into file 221904.
Inserting data attribute into file 221905.
Inserting data attribute into file 221906.
Inserting data attribute into file 221907.
Inserting data attribute into file 221908.
Inserting data attribute into file 221910.
Inserting data attribute into file 221911.
Inserting data attribute into file 221912.
Inserting data attribute into file 221915.
Inserting data attribute into file 221925.
  49030 data files processed.                                            CHKDSK is verifying Usn Journal...
  36868184 USN bytes processed.                                             Usn Journal verification completed.
Correcting errors in the master file table's (MFT) BITMAP attribute.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

 291987455 KB total disk space.
 185120652 KB in 171472 files.
    105856 KB in 49015 indexes.
         0 KB in bad sectors.
    334419 KB in use by the system.
     65536 KB occupied by the log file.
 106426528 KB available on disk.

      4096 bytes in each allocation unit.
  72996863 total allocation units on disk.
  26606632 allocation units available on disk.

Internal Info:
00 63 03 00 61 5d 03 00 a4 0b 06 00 00 00 00 00  .c..a]..........
ca 05 00 00 2c 00 00 00 00 00 00 00 00 00 00 00  ....,...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Windows has finished checking your disk.
Please wait while your computer restarts.

This has been happening off and on since Fedora 15, which ranges from annoying ("Oh, lost some random meme gifs I downloaded") to angering ("Oh look, my programming assignment was deleted"). Its to the point where I'm about to mount the partition as read-only, which means I'll probably not use Linux at all.

EDIT: Mount options

/dev/sda2 /media/win7/ ntfs rw,uid=1000,gid=1000,umask=007 0 0

Has anyone else ever experienced this problem? Are there known remedies? Is NTFS on Windows 7 even supported?

3 Answers 3

5
+25

Try using the ntfs-3g driver on fedora instead of ntfs. It should already be installed by default in the latest fedora.

To test you can do:

 mount -t ntfs-3g /dev/sda2 /mnt/win7

If it works then you can add it to your fstab:

/dev/sda2 /media/win7/ ntfs-3g rw,uid=1000,gid=1000,umask=007 0 0

More info (bit old but still relevant): http://fedorasolved.org/post-install-solutions/ntfs-read-write/

2
  • Wow, I'm going to be pissed if that's the real reason why.
    – TheLQ
    Aug 9, 2012 at 23:40
  • I was afraid of this: Seems its hard to replicate the filesystems errors reliably. So for now I think I'm going to let it run for a while and see if daily use triggers the errors again. In the mean time I'll see if any other answers roll in
    – TheLQ
    Aug 10, 2012 at 0:24
0

I've had bad experiences with NTFS on linux. Eventually when I wanted to share a partition, I'd just formatted as FAT if the partition didn't need to be too large. The problem, as I understand it, is that the NTFS drivers for linux aren't written by MS and MS hasn't been very helpful in providing details for an implementation by perfect compatibility.

If you don't need your Fedora machine to be cutting edge fast, you could use VirtualBox to run the linux as guest and set up SAMBA sharing instead.

2
  • I've been using NTFS-formatted 500G & 1T external drives with linux (for media storage) for the last few years without any problems...
    – rsaw
    Aug 10, 2012 at 16:46
  • I have one external media drive I use for media w/ NTFS that works great with both OS, but for the /home drive it's always failed with me. My media drive is rarely mounted and always unmounted neatly. Also, I'll admit I've given up on NTFS on linux a few years ago so it might be better. But I've lost too much data to care to try again.
    – user21272
    Aug 10, 2012 at 17:20
-1

It might be because it is encrypted. It might try to encrypt it on the fly and then save it, as it knows the disk you are trying to save to is encrypted. However, it does not know that it is a symlink.

1
  • From what he said, his filesystem "sits on a roughly 20GB encrypted partition". The wording here, coupled with the fact that he's using Fedora and not Ubuntu, almost certainly means the underlying block device is encrypted (via dm-crypt) -- this is below the filesystem level and irrelevant to the issue he's describing. For the record: even if it was eCryptfs on top of the filesystem, it wouldn't matter. When the encrypted filesystem was open, the symlinks would pass through as symlinks always do; when it was closed, they wouldn't.
    – rsaw
    Aug 10, 2012 at 16:44

You must log in to answer this question.

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