You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(30) |
May
(47) |
Jun
(37) |
Jul
(63) |
Aug
(55) |
Sep
(56) |
Oct
(36) |
Nov
(24) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(60) |
Feb
(32) |
Mar
(39) |
Apr
(14) |
May
(17) |
Jun
(13) |
Jul
(22) |
Aug
(33) |
Sep
(70) |
Oct
(48) |
Nov
(30) |
Dec
(4) |
| 2006 |
Jan
(13) |
Feb
(8) |
Mar
|
Apr
(3) |
May
(8) |
Jun
(10) |
Jul
(13) |
Aug
(9) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(24) |
Jul
(1) |
Aug
(1) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-09-21 21:42:06
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3349156 By: nobody So for everyone who is interested in this matter. a directory contains 2 attributes among others. $AttrIndexRoot and $AttrIndexAllocation $AttrIndexRoot starts with INDEX_ROOT structure which has a member Attribute Type which tells us what is indexed in the index entries. After this header follows a secquence of index entries. An indexentry contains an INDEX_HEADER which tells the size of the index , where the index starts and the index itself. $AttrIndexAllocation contains a secquence of INDX records. An INDX record contains an INDX header (be careful to remove the fixups) and a secquence of index entries as described above. The problem is far more complicated but I've tried to make some sense in this issue. I am very sorry to say that the documentation regarding the directories in NTFS is poor and faulted in some parts or I am so dumb so I cannot read between the lines. Anything else is perfect ;) Thank you , ugluk ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 14:50:02
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3348398 By: nobody OK, I found the problem. I was assuming that a FILE record always starts at the beginning of the cluster (well, I knew it doesn't, but it seems I didn't include this is my code). So, I was always removing the fixups from the first two sectors of each cluster... that was stupid. Anyway, thanks a lot for your help. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 12:12:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3348137 By: flatcap Hmm... Hang on. Let's go back a bit. You have a cluster size of 4K, but the MFT (FILE) records will only be 1K in size. So, the size of the update sequence array will be 3 (sequence number + 2 fixups). We were talking about fixups that didn't exist! To remove the fixup (forgive me if you know this already), you check the sequence number matches the end of every sector, then write the first fixup number over the end of sector one, the second over the end of sector two, etc. Check carefully that's what you've done. If you're still having trouble, post a hex dump of the FILE record, or better still put a binary copy of the 1K FILE record somewhere public -- I'll try and find the time to dcode it for you. Cheers, FlatCap (Rich) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 11:23:57
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3348059 By: nobody I feel stupid right now, I just don't get it. The FILE header tells me that the array size is 3 words (6 bytes), so the first one is the update sequence number and the next 2 are the fixups! So, even if the latter sector-ends were zero bytes, shouldn't the fixup array contain them? Obviously there's something here I don't understand... please explain in detail if you can. Thanks for your time. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 11:13:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3348047 By: flatcap Argh! You have to remove the fixup from every sector. It may not _look_ like there's more fixups in the array, but that's because the original values of the latter sector-ends were zero. Make sense? If you look at the FILE header, it will tell you exactly how many words of data (including the update sequence number). http://linux-ntfs.sourceforge.net/ntfs/concepts/file_record.html Cheers, FlatCap (Rich) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 09:55:00
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3347961 By: nobody Hi again. I'm the guy who started the thread. Thanks for all the replies. There's still something wrong here: On my HD, the NTFS cluster size is 4KB and the sector size is 512B. So I have 8 sectors per cluster. Now, the mft record I'm trying to read has an update sequence array which contains only 2 words of data (not including the update sequence number itself). So, i remove the fixups of the first two sectors of the cluster. However, I still read the wrong length value for attribute 0x80, because this value is stored at the end of sector 7 within the cluster... so, shouldn't the update sequence array contain more elements in order to cover every sector in the cluster? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-21 00:59:56
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3347522 By: nobody also... http://sourceforge.net/projects/umfs has c++ ntfs implementation. (readonly) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-20 23:45:18
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3347459 By: nobody Damn.I know I was missing something... thanks a lot man. I believe this is the problem. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-20 23:22:49
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3347438 By: nobody Have you removed the fixup? http://linux-ntfs.sourceforge.net/ntfs/concepts/fixup.html ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-20 23:00:19
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3347416 By: nobody Hi. I'm trying to navigate through every file on an NTFS volume using a C++ program I've been writing in the last few days. I have read your NTFS documentation and I'm working based on it. Now here's the problem: I have a FILE record containing the following attributes: 0x10, 0x30, 0x30, 0x80. The last attribute ($DATA) is resident because the file is really small (43 bytes). However, the attribute header says that the attribute length is 0x00030048, although it should be 0x00000048! I used a disk editor under Windows and saw that the strange value I read is really there. However, I downloaded "ntexplorer" from www.runtime.org and when it reads the same attribute for the same file it gives me a length of 0x00000048! So, that application probably does something different and reads the correct value. Maybe the length is not 4-bytes long but only 2-bytes long?? I don't know what to say, this is really strange because it happens only on a specific file (up to now). Thanks in advance. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-20 10:11:43
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3346376 By: szaka Thanks for the output Scott, it was useful. Nobody ever reported such problem over the last three years, maybe you have found some interesting thing. But first a clarification (sorry if I seem to be annoying but it's very important). The check happens the below way, right? - chkdsk /f (and "yes" for the question) - reboot Windows - chkdsk is running now (3 passes on a blue background) - chkdsk automatically reboots - Windows boots again but no chkdsk this time - you boot Linux and the above error still exists OK, if the above is the case then here is some comments based on the output. You use a somewhat old RIP: the ntfsresize version is 1.12.0-WIP (WIP = Work In Progress) which was a development version for a very short time right after the 1.11.1 release. 1.12.0-WIP was shortly renamed to 1.11.2-WIP then we had the stable 1.11.2 release. Currrently the development version is called 1.11.3-WIP. All this means is that the changes made during 1.11.1 and 1.11.2 didn't make into the version RIP uses. During between this two releases there was one fix which could solve your problem (it was a problem in theory only, nobody ever seen it in practice so far). So, please also try the latest RIP, version 14.4, which uses ntfsresize 1.11.3-WIP (it's absolutely the latest ntfsresize version currently): http://www.tux.org/pub/people/kent-robotti/looplinux/rip/ If you would still have the same problem then could you please create the metadata of your NTFS for detailed inspection? You can also use RIP to do it: ntfsclone --ignore-fs-check -mo inconsistent-ntfs.img /dev/hda1 bzip2 inconsistent-ntfs.img This can be a bit slow (from several to tens of minutes) and the bzip2 compressed NTFS metadata-only file should be around 8-16 MB. You could put it somewhere online and send me privately the URL to sz...@si... and I'll investigate it. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-20 02:58:34
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3346002 By: firecat53 I've done the chkdsk /f (and /f /r)(it runs through its checks without any issues) and restarted twice and I still get the following errors when I attemp ntfsresize: ntfsresize v1.12.0-WIP Device name : /dev/hda1 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 61492158976 bytes (61493 MB) Current device size: 61492161024 bytes (61493 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Cluster accounting failed at 127 (0x7f): extra cluster in $Bitmap Cluster accounting failed at 1310 (0x51e): extra cluster in $Bitmap Cluster accounting failed at 42608 (0xa670): extra cluster in $Bitmap Cluster accounting failed at 142022 (0x22ac6): extra cluster in $Bitmap Cluster accounting failed at 142023 (0x22ac7): extra cluster in $Bitmap Cluster accounting failed at 142024 (0x22ac8): extra cluster in $Bitmap Cluster accounting failed at 142025 (0x22ac9): extra cluster in $Bitmap Cluster accounting failed at 142026 (0x22aca): extra cluster in $Bitmap Cluster accounting failed at 142027 (0x22acb): extra cluster in $Bitmap Cluster accounting failed at 142028 (0x22acc): extra cluster in $Bitmap ERROR: Filesystem check failed! Totally 2766 cluster accounting mismatches. Apparently you have a corrupted NTFS. Please run the filesystem checker on Windows by invoking chkdsk /f. Don't forget the /f (force) parameter, it's important! You probably also need to reboot Windows to take effect. Then you can try ntfsresize again. No modification was made to your NTFS. Any thoughts?? thanks, Scott ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-19 22:50:55
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3345851 By: szaka You need the latest ntfsresize, version 1.11.2. None of the SystemRescueCD version will work, they are too old. I didn't have time for a while to check out which easy-to-use distros use the latest ntfsresize (well, so far at least SUSE 10.0 beta, RIP, Debian unstable, Mandriva beta but they are too big to download or don't have GUI). ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-19 16:07:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3344995 By: szaka Defrag is completely irrelevant and chkdsk /f must fix the NTFS inconsistency which was created by the Windows NTFS driver. You must also boot twice into Windows after running chkdsk /f and don't forget to say "yes" when Windows asks about if you really want the boot time check. Some people don't do this and Windows won't detect and fix the problem. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-18 19:57:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3343960 By: uvman Fresh FC4 comes with 2.6.11 kernel, you are installing the module for 2.6.12-1.1447 Try to type "uname -r" in order to find out if you are installing the right module. The following url may help you further: http://linux-ntfs.sourceforge.net/rpm/instructions.html ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-18 18:32:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3343890 By: dan_solo Specs: Pentium 4 2.8 prescott Asus p4p800 SE 512 ddr400 Maxtor 160gb SATA gf6600GT Fresh Fedora C4 install I've downloaded the following package: kernel-module-ntfs-2.6.12-1.1447_FC4smp-2.1.22-0.rr.7.4.i686.rpm Changed in inittab runlevel to 3 restarted Logged as root ran rpm -ihv kernel... everything fine till now when i do modprobe ntfs.. it appears the message saying that the module doesn't exist. I tried to reinstall, and it says it is already installed.. then i uninstalled it correctly, reinstalled everything went fine.. still it can't find ntfs module. This is currently the weirdest problem i've ever had lol same ocurred to me while installing TLS module for Amsn, installed fine.. but.. it's like it didn't. I know my fedora must have some problem to have this issues with rpms.. i wonder if anyone can help me :) Thanks ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 18:13:41
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3335501 By: nobody The problem is that while reading the documentation i felt like trapped in a maze. Please correct me where i am wrong Directory parsing starts with INDEX_ROOT - resident attr_header Index Root : { 0x00 4 Attribute Type 0x04 4 Collation Rule 0x08 4 Size of Index Allocation Entry (bytes) 0x0C 1 Clusters per Index Record 0x0D 3 Padding (Align to 8 bytes) } Index Header { 0x00 4 Offset to first Index Entry 0x04 4 Total size of the Index Entries 0x08 4 Allocated size of the Index Entries 0x0C 1 Flags 0x0D 3 Padding (align to 8 bytes) } index entry index entry How is described index entry in this attribute because it is unlikely to contain an INDX record (must be>2k) and a record size is 1k than INDEX_ALLOCATION - non resident data runs here I get lost INDX_RECORD???? INDEX_ENTRY????? Thank you ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44084 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 11:22:03
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334538 By: j0nek thanks, I'll try that jonek ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 07:19:45
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334267 By: uvman That error means that the volume is inconsistent. In simple terms, $Bitmap is a system file that stores for each cluster if it is clear or taken. but the size of $Bitmap does match the size of the volume. At the moment there is no fsck for NTFS in Linux, so you could restore it with dd back to some partition, boot Windows and run 'chkdsk /f' on that volume, or wait to such a tool to be constructed (no date exists) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 06:58:08
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334253 By: paulway Ah. 0.2.15, you say. Right. Downloaded and burning now. Will ntfsresize really run on a looped filesystem? Wow! Clever. 'sgonna take some time to back up, but at least now I know it'll work if the new tools don't. Will keep you posted, Paul ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 06:32:53
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334233 By: nobody I have solved the problem. I download ntfsprogs from cvs and get work it. Thank you for your grace Job! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 06:27:35
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334230 By: uvman I forgot to mention: ntfsclone is unable to restore the image back to a smaller partition (unlike ghost). But you can mount the generated image, run ntfsresize on it (the old one you use will not work, but a newer one should) and then restore it. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 06:24:34
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334228 By: uvman ntfsmount is not able to delete all files, as well as does not always manage to create files. You could wait for it to be implemented or use another NTFS driver (The best one is in Windows ;-) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 06:22:27
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334226 By: uvman SystemRescueCD 0.2.7 is really old. Even the latest SystemRescueCD is a year old, but should work much better. Your best option is RIP (http://www.tux.org/pub/people/kent-robotti/looplinux/rip/). ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
|
From: SourceForge.net <no...@so...> - 2005-09-12 05:44:46
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3334202 By: nobody Thank you for your answer. After reboot in windows i can mount my partition in linux gracefully. Next question - i try delete file on mounted partition and get message "Operation not supported". How i can do it? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=44085 |
