Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

How screwed am I? (Partition Problem)

- - - - -

  • Please log in to reply
30 replies to this topic

#1
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

I was resizing a partition on one of my laptops to make room for an Ubuntu installation using Partition Wizard. when PW finished, I restarted my Pc and the installation of W7 that was on the partition that I shrunk bluescreened while showing the Startung Windows... screen. The other OS on the drive is fine. When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

 

The only problem is that this is on an OCZ Vertex 4 so would I be able to use traditional recovery software or not?




How to remove advertisement from MSFN

#2
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Which "other" OS?

 

First thing you should do, in any case, is to make a "forensic sound" or "dd-like" image of the disk (you will need a slightly larger disk) or make a "clone" (you will need a "same size" disk.

 

If the "other OS" (or the PE/liveCD/whatever) you are going to boot does not send automagically the TRIM command, there should be no differences (I believe that the OCZ has not an "automatic garbage collector", but even if it has, it should be about "deleted" files and not about a partiion that became RAW) from a "normal" hard disk recovery.

 

jaclaz



#3
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

Which "other" OS?

 

First thing you should do, in any case, is to make a "forensic sound" or "dd-like" image of the disk (you will need a slightly larger disk) or make a "clone" (you will need a "same size" disk.

 

If the "other OS" (or the PE/liveCD/whatever) you are going to boot does not send automagically the TRIM command, there should be no differences (I believe that the OCZ has not an "automatic garbage collector", but even if it has, it should be about "deleted" files and not about a partiion that became RAW) from a "normal" hard disk recovery.

 

jaclaz

The other OS is Windows 7 x86. A check of disabledeletenotify shows that TRIM seems to be enabled but since TRIM is for just files and this OS didn't come in contact with the other partition before the partition got changed into that Unalloc\Raw mix, wouldn't that mean that TRIM can't do anything?

 

Also, since I'm currently away from home, I don't have any drives that are large enough (I do have one, but it is half full with data that wouldn't fit elsewhere).

 

I may be asking this question slightly too early, but if I get what seems like all of the data off my drive (since with SSDs, it most probably would be all or nothing), would it be better to try and recreate the OS using that or just reinstall and dump the data?


Edited by Torchizard, 02 November 2013 - 04:43 AM.


#4
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

The point is that right now you have provided some symptoms only.

We need to make a diagnosis instead to say what may happen (with any degree of accuracy).

 

It is well possible that by just correcting a bunch of bytes you can restore the volume exactly as it was :) or it is possible that you cannot recover any data of any kind :(.

 

We have to understand what happened first thing.

 

The point of copying the data to another disk is - besides good practice and "common sense" - in this particular case that of making sure that no TRIM or actually "garbage collection" happens.

 

The generic risk when doing data recovery (no matter if on a SSD or an hard disk) is that attempting a given approach, this approach may make a subsequent different approach impossible (or not working, while it may have worked if the earlier attempt was not made), having a "forensic sound" image allows one to be able to re-start form scratch at will.

 

jaclaz



#5
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag
The point of copying the data to another disk is - besides good practice and "common sense" - in this particular case that of making sure that no TRIM or actually "garbage collection" happens.

The generic risk when doing data recovery (no matter if on a SSD or an hard disk) is that attempting a given approach, this approach may make a subsequent different approach impossible (or not working, while it may have worked if the earlier attempt was not made), having a "forensic sound" image allows one to be able to re-start form scratch at will.

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.



#6
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.

 

I do understand that, but I have to tell you the reason why it was suggested and the risk that you may face by being not able to follow that advice.

 

So, next step is to get and run TESTDISK, to have hopefully a general idea of the issue.

You want to create a LOG and to post it as an attachment to your next reply.

http://www.cgsecurit...g/wiki/TestDisk

http://www.cgsecurit...sk_Step_By_Step

When asked if you want to look for partitions created under Vista, answer Yes.

DO NOT, and I mean DO NOT take any action unless you are VERY, VERY sure about what you are doing before having posted the LOG and having got a reply with possible diagnosis/set of recovery instructions.

 

jaclaz



#7
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

 

As I kinda said before, unless there is a way to ghost the drive and split it into multiple volumes as none that I currently have are large enough, I won't be able to create that image.

 

I do understand that, but I have to tell you the reason why it was suggested and the risk that you may face by being not able to follow that advice.

 

So, next step is to get and run TESTDISK, to have hopefully a general idea of the issue.

You want to create a LOG and to post it as an attachment to your next reply.

http://www.cgsecurit...g/wiki/TestDisk

http://www.cgsecurit...sk_Step_By_Step

When asked if you want to look for partitions created under Vista, answer Yes.

DO NOT, and I mean DO NOT take any action unless you are VERY, VERY sure about what you are doing before having posted the LOG and having got a reply with possible diagnosis/set of recovery instructions.

 

jaclaz

 

So I used TestDisk and it seems to have found the partition. When I select it, it also seems to show all the folders\files that were on there before. It didn't ask me about vista partitions but it still showed the partition. 

 

I don't see the option to upload files anywhere on here so here's a Pastebin link instead: http://pastebin.com/3FEHRDnx



#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Good :).

It seems a "plain" MBR partition table corruption error.

This is what your disk looks like:

 

Analyse Disk /dev/sda - 512 GB / 476 GiB - CHS 62260 255 63

Geometry from i386 MBR: head=255 sector=63

NTFS at 0/32/33

NTFS at 1839/242/4

Info: size boot_sector 663453689, partition 663453696

NTFS at 49512/34/59

Current partition structure:

1 * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

2 P HPFS - NTFS           1839 242  4 43138   8  6  663453696

3 P HPFS - NTFS          49512  34 59 62260  88 36  204800000

 

 

And this is how it should look (according to TESTDISK):

 

Results

   * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

     NTFS, blocksize=4096, 104 MB / 100 MiB

   P HPFS - NTFS             12 223 20 49512  34 58  795205632

     NTFS, blocksize=4096, 407 GB / 379 GiB

   P HPFS - NTFS          49512  34 59 62260  88 36  204800000

     NTFS, blocksize=4096, 104 GB / 97 GiB

 

interface_write()

1 * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

2 P HPFS - NTFS             12 223 20 49512  34 58  795205632

3 P HPFS - NTFS          49512  34 59 62260  88 36  204800000

simulate write!

 

The first and last partitions appear the same (and correct).

The one in the middle does not.

If by accessing it through TESTDISK with the "simulated written" new partition table you can actually see it's contents (directories/files) it should mean that the whatever you used to resize the "middle" partition did not do it's job or was interrupted before updating the partition table.

The partitioning that TESTDISK found appears correct. :)

 

Now, it's up to you.

 

You can decide to first save the data (only the really meaningful one, i.e. something that you really-really cannot replace/reinstall/recreate) by copying the files from the disk through the TESTDISK (temporary/volatile) access through the "p" (of course these files need to be copied to another disk drive) manually.

 

And after re-run testdisk (append to the log, just in case) and repeat the analysis then write the changes:

http://www.cgsecurit..._table_recovery

 

Or directly do the writing of the correct partition table.

 

In any case, the first thing that will be needed, after the new partition table is written and a reboot, would be a CHKDSK on the volume.

 

BUT there is something "queer" (that needs to be cleared) BEFORE doing anything of the above.

You reported:

 

When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

 

What you will have after writing the partition table will be:

100 Mb System partition Primary (like you have now) 204800x512=104857600

400 Gb partition Primary 795205632x512=407145283584

100 Gb partition Primary 204800000x512=104857600000

that would be the same as you had before even attempting to shrink the middle partition.

even if the "roughly" 100 Gb last partition corresponds to the 90 Gb one you saw, the math doesn't sound right, 14+300+50, even roughly, does not match the current 400 Gb (which instead sounds right).

The last partition is 104,857,600,000, i.e. around 100 or 98 Gb (depending on how it is measured)

In the "current" setup the "gap" between first and second partition is 15,028,191,232 bytes (which would correspond to the 14 Gb you saw), the "middle" (wrong) partition is 339,688,292,352 (which would be seen as a 316 or 324 Gb partition) and the "gap" before the last partition is 52,428,800,000, i.e. seen as 50 Gb.

Is it possible that you reported 300 instead of 316 or 324?

Compare with the table:

 

 

jaclaz

 

Heck the table cannot be attached, find it here:

http://www2.zshares.net/lu50vdy9cz84


Edited by jaclaz, 03 November 2013 - 04:20 AM.


#9
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

Good :).

It seems a "plain" MBR partition table corruption error.

This is what your disk looks like:

 

Analyse Disk /dev/sda - 512 GB / 476 GiB - CHS 62260 255 63

Geometry from i386 MBR: head=255 sector=63

NTFS at 0/32/33

NTFS at 1839/242/4

Info: size boot_sector 663453689, partition 663453696

NTFS at 49512/34/59

Current partition structure:

1 * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

2 P HPFS - NTFS           1839 242  4 43138   8  6  663453696

3 P HPFS - NTFS          49512  34 59 62260  88 36  204800000

 

 

And this is how it should look (according to TESTDISK):

 

Results

   * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

     NTFS, blocksize=4096, 104 MB / 100 MiB

   P HPFS - NTFS             12 223 20 49512  34 58  795205632

     NTFS, blocksize=4096, 407 GB / 379 GiB

   P HPFS - NTFS          49512  34 59 62260  88 36  204800000

     NTFS, blocksize=4096, 104 GB / 97 GiB

 

interface_write()

1 * HPFS - NTFS              0  32 33    12 223 19     204800 [System Reserved]

2 P HPFS - NTFS             12 223 20 49512  34 58  795205632

3 P HPFS - NTFS          49512  34 59 62260  88 36  204800000

simulate write!

 

The first and last partitions appear the same (and correct).

The one in the middle does not.

If by accessing it through TESTDISK with the "simulated written" new partition table you can actually see it's contents (directories/files) it should mean that the whatever you used to resize the "middle" partition did not do it's job or was interrupted before updating the partition table.

The partitioning that TESTDISK found appears correct. :)

 

Now, it's up to you.

 

You can decide to first save the data (only the really meaningful one, i.e. something that you really-really cannot replace/reinstall/recreate) by copying the files from the disk through the TESTDISK (temporary/volatile) access through the "p" (of course these files need to be copied to another disk drive) manually.

 

And after re-run testdisk (append to the log, just in case) and repeat the analysis then write the changes:

http://www.cgsecurit..._table_recovery

 

Or directly do the writing of the correct partition table.

 

In any case, the first thing that will be needed, after the new partition table is written and a reboot, would be a CHKDSK on the volume.

 

BUT there is something "queer" (that needs to be cleared) BEFORE doing anything of the above.

You reported:

 

When I looked at drive management on the other OS, it showed something simmilar to:

100Mb system reserved, 14Gb unallocated space, 300Gb RAW(part of the corruupted os with the 14Gb unallocated), 50Gb unallocated (planned for Ubuntu) and 90GB (my other OS).

 

What you will have after writing the partition table will be:

100 Mb System partition Primary (like you have now) 204800x512=104857600

400 Gb partition Primary 795205632x512=407145283584

100 Gb partition Primary 204800000x512=104857600000

that would be the same as you had before even attempting to shrink the middle partition.

even if the "roughly" 100 Gb last partition corresponds to the 90 Gb one you saw, the math doesn't sound right, 14+300+50, even roughly, does not match the current 400 Gb (which instead sounds right).

The last partition is 104,857,600,000, i.e. around 100 or 98 Gb (depending on how it is measured)

In the "current" setup the "gap" between first and second partition is 15,028,191,232 bytes (which would correspond to the 14 Gb you saw), the "middle" (wrong) partition is 339,688,292,352 (which would be seen as a 316 or 324 Gb partition) and the "gap" before the last partition is 52,428,800,000, i.e. seen as 50 Gb.

Is it possible that you reported 300 instead of 316 or 324?

Compare with the table:

 

 

jaclaz

 

Heck the table cannot be attached, find it here:

http://www2.zshares.net/lu50vdy9cz84

Yeah, the values that I said were only rough estimates, based only on the first digit. 

What it actually reports is:
100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)



#10
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

[Off-Topic] Sorry to interrupt, but... both of you are not being able to attach to this thread, because the full editor in not offering the "Attach Files" interface? If so, let me know and I'll try to get it fixed fast, because that sure is serious... [/Off-Topic]



#11
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

[Off-Topic] Sorry to interrupt, but... both of you are not being able to attach to this thread, because the full editor in not offering the "Attach Files" interface? If so, let me know and I'll try to get it fixed fast, because that sure is serious... [/Off-Topic]

Yeah, on one of my previous topics I attached a file and now when I was looking for the attach button, I spent five minutes trying to find something which I previously remembered existing. 

 

[Offtopic] My post number is now the meaning of life! [/Offtopic]


Edited by Torchizard, 03 November 2013 - 04:46 AM.


#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

Yeah, the values that I said were only rough estimates, based only on the first digit. 

....

What it actually reports is:
100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)

 

Good. :) Everything seems fine then, maybe excepted to the meaning of life of the verbs "to round" and to "approximate". ;)

And in any case that is the answer to the ultimate question about life, the universe an everything, not about the meaning of liff of life, which it's nothing much special:

http://www.imdb.com/...?item=qt0256724

M-hmm. Well, it's nothing very special. Uh, try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations.

 

:yes:

 

@dencorso

What I see below Attach Files

 

Attach This File    You can upload up to Uploading is not allowed of files (Max. single file size: 100MB)

 

 

And NO :no:

Try our advanced uploader (requires Flash 9)

 

I am not even THINKING of trying the advanced uploader (what i call "retarded flash based bloat" ;))

 

 

jaclaz


Edited by jaclaz, 03 November 2013 - 05:11 AM.


#13
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

 

 

Yeah, the values that I said were only rough estimates, based only on the first digit. 

....

What it actually reports is:
100Mb System Reserved

14Gb Unallocated

316.36Gb RAW

48.83 Unallocated (The amount I resized)

97.66Gb (Other OS)

 

Good. :) Everything seems fine then, maybe excepted to the meaning of life of the verbs "to round" and to "approximate". ;)

And in any case that is the answer to the ultimate question about life, the universe an everything, not about the meaning of liff of life, which it's nothing much special:

http://www.imdb.com/...?item=qt0256724

M-hmm. Well, it's nothing very special. Uh, try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations.

 

:yes:

 

@dencorso

What I see below Attach Files

 

Attach This File    You can upload up to Uploading is not allowed of files (Max. single file size: 100MB)

 

 

And NO :no:

Try our advanced uploader (requires Flash 9)

 

I am not even THINKING of trying the advanced uploader (what i call "retarded flash based bloat" ;))

 

 

jaclaz

 

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?



#14
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?

 

Yes and no. :w00t:

 

Meaning that with 99% of probabilities, since you can see your files in the "simulated" partition scheme that TESTDISK found, it should mean that the filesystem is OK, i.e. it is very probable that the tool you attempted using to shrink/resize the partition simply wrote the current (wrong) entry in the partition table and failed/crashed/exited without modifying the filesystem :).

 

But it is well possible that the filesystem suffered from some damage :(.

 

Until you do not write the "good" partition table and reboot, you can copy files manually (through the TESTDISK interface) "as they are".

 

Once you reboot there are two possibilities:

  1. the volume is marked for an automatic CHKDSK  ("dirty" flag)
  2. the volume is NOT marked for an automatic CHKDSK

In any case, as said, running a CHKDSK is strongly encouraged as first thing.

 

Now, when you run CHKDSK without knowing if there is a damage in the filesytem (or the extents of this damage) you cannot know in advance what will happen.

If there are no damages, then there won't be any problem.

If the damage are small/trifling or however "repairable", again there won't be any problem.

If the damage is serious, there  is a concrete chance that CHKDSK won't be able to fully repair the volume and the process of running CHKDSK may even make a given file not recoverable anymore.

 

And we are back to the general advice of always imaging a disk that presented issues, so that you can "go back" and try something else if what you are doing failed.

 

As said, I do understand why you are not able to do that, but from there to make me say "Ah, well then it's OK, no need to image the disk, just write the partition table and everything will be OK" there is quite a largish leap.

Most probably there are no damages to the filesystem or they are fixable by CHKDSK (and there won't be any issues even when attempting booting form that volume), but you won't :no: manage to make me tell you "Go ahead, no prob whatsoever", as YMMGV.  :unsure:

 

jaclaz



#15
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

 

 

So would I be fine to go ahead and write the partitions to disk?

Also, would I be able to use currently "buried" OS like before?

 

Yes and no. :w00t:

 

Meaning that with 99% of probabilities, since you can see your files in the "simulated" partition scheme that TESTDISK found, it should mean that the filesystem is OK, i.e. it is very probable that the tool you attempted using to shrink/resize the partition simply wrote the current (wrong) entry in the partition table and failed/crashed/exited without modifying the filesystem :).

 

But it is well possible that the filesystem suffered from some damage :(.

 

Until you do not write the "good" partition table and reboot, you can copy files manually (through the TESTDISK interface) "as they are".

 

Once you reboot there are two possibilities:

  1. the volume is marked for an automatic CHKDSK  ("dirty" flag)
  2. the volume is NOT marked for an automatic CHKDSK

In any case, as said, running a CHKDSK is strongly encouraged as first thing.

 

Now, when you run CHKDSK without knowing if there is a damage in the filesytem (or the extents of this damage) you cannot know in advance what will happen.

If there are no damages, then there won't be any problem.

If the damage are small/trifling or however "repairable", again there won't be any problem.

If the damage is serious, there  is a concrete chance that CHKDSK won't be able to fully repair the volume and the process of running CHKDSK may even make a given file not recoverable anymore.

 

And we are back to the general advice of always imaging a disk that presented issues, so that you can "go back" and try something else if what you are doing failed.

 

As said, I do understand why you are not able to do that, but from there to make me say "Ah, well then it's OK, no need to image the disk, just write the partition table and everything will be OK" there is quite a largish leap.

Most probably there are no damages to the filesystem or they are fixable by CHKDSK (and there won't be any issues even when attempting booting form that volume), but you won't :no: manage to make me tell you "Go ahead, no prob whatsoever", as YMMGV.  :unsure:

 

jaclaz

 

So I restored the partition table and from my other OS, the drive was accessible. CHKDSK never showed up. I tried booting the OS but it restarted as soon as I selected it so I ran startup repair off a DVD  which said it corrected some problems. So after that , the second OS booted just fine like before but the original OS went past the starting windows screen and then said that 'pwnative' and 'autochk' were missing and that they were skipped. Then it went to a bluescreen saying that the Session Manager Initialization system process terminated unexpectedly. 

Now for some weird reason, the second OS won't start correctly unless it is in safe mode.   Never mind, it just derped during resuming from sleep. 

 

Edit 2: On the original system, I selected Last known boot configuration and it worked, IT BOOTS!!!!!!  :w00t:  :w00t:

 

Edit 3: It seems CHKDSK does not want to co-operate as it says the path is invalid whenever I try to run it. 


Edited by Torchizard, 03 November 2013 - 07:03 AM.


#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

It's good to see how you follow advice :unsure:.

 

The advice was:

  1. boot to the second OS
  2. run CHKDSK from it first thing

The "autochck" message roughly means that the NTFS filesystem was actually marked as "dirty" and it attempted autorunning CHKDSK (but failed).

 

Now, take a deep breath.

Boot to the second OS.

From it, run CHKDSK on the "original" OS volume.

Run it in three stages (let's say that when booted to the second OS the "original" OS volume is drive letter D::

  1. CHKDSK D:
  2. CHKDSK D: /F
  3. CHKDSK D: /R

Change drive letter accordingly to your settings if needed. 

 

When you run the CHKDSK D: without parameters it should tell you that it found errors but that it could not repair them because parameter /F was not specified.

Post any error different from the above.

 

jaclaz 



#17
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator


@dencorso

What I see below Attach Files

 

Attach This File    You can upload up to Uploading is not allowed of files (Max. single file size: 100MB)

 

 

jaclaz

 

Uhhh! :crazy: Something is really very amiss, here!

So, please do bear with me and do some experimenting:

 

You get "You can upload up to Uploading is not allowed of files" ...

 

  • just in this single thread

     

  • just in this sub-forum

     

  • both in this sub-forum and in its container forum

     

  • throughout all the forums

 

TIA for your patience! :thumbup



#18
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

The same happens in "Windows Setup from USB" (of which I am also "moderator" - though "child of a lesser God" ;)) so I would say that it is "Board wide".
Maybe I have exceeded my overall "quota" ? :unsure:
 
I'll check my control panel (if I can find that page, I remember having seen once or twice) and report.
 
jaclaz
 
EDIT:
P.S. That's probably it:

Manage Attachments
You have used 7.15MB of 4.88MB
100%
You have 117 attachments (100% used)

Now, I may do with some extension to my quota (generally speaking) but most probably I found the culprit. :yes:
It's likely Tripredacus :w00t: :ph34r: he sent me a small (around 2.5 Mb) image of a CD from which he wasn't able to extract the internal [Boot] image through my little batch here (shameless plug):
http://reboot.pro/to...ting-iso-files/
http://reboot.pro/to...e-2#entry108486
very likely because he was running it into a stupid 7 or 8 - possibly even on a 64 bit system (besides using spaces and bangs "!" in file/folder names).
I extracted it and attached the result to a reply, and that probably messed up the counter or whatever (it should have not allowed me the upload then, I guess it is one of the usual "by design" things from the good IPB guys).
Will try deleting that attachment and see if situation changes.
 
EDIT2:
Confirmed:

Manage Attachments
You have used 4.76MB of 4.88MB
98%
You have 116 attachments (98% used)


Now (on this very thread):
 

Attach Files
You can upload up to 4.88MB of files (Max. single file size: 4.88MB)

 

It seems very like the good IPB guys (and/or *something* in the specific board settings) do not have a very clear idea of the difference between a "quota" and a "single file size" ...


Edited by jaclaz, 03 November 2013 - 10:21 AM.


#19
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

It's good to see how you follow advice :unsure:.

 

The advice was:

  1. boot to the second OS
  2. run CHKDSK from it first thing

The "autochck" message roughly means that the NTFS filesystem was actually marked as "dirty" and it attempted autorunning CHKDSK (but failed).

 

Now, take a deep breath.

Boot to the second OS.

From it, run CHKDSK on the "original" OS volume.

Run it in three stages (let's say that when booted to the second OS the "original" OS volume is drive letter D::

  1. CHKDSK D:
  2. CHKDSK D: /F
  3. CHKDSK D: /R

Change drive letter accordingly to your settings if needed. 

 

When you run the CHKDSK D: without parameters it should tell you that it found errors but that it could not repair them because parameter /F was not specified.

Post any error different from the above.

 

jaclaz 

 

CHKDSK says it doesn't find any problems on either one of the partitions.

Also, I ran SFC and that said it had a few problems, should I post that log? 



#20
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

CHKDSK says it doesn't find any problems on either one of the partitions.

Also, I ran SFC and that said it had a few problems, should I post that log? 

 

This is strange.

I mean the autochk is connected to the *need* to run chkdsk to fix some issue (evidently of a minor kind, since that volume booted afterwards).

I would run CHKDSK /F anyway on that volume, next.

Yes, post the SFC log, though most probably those problems are unrelated.

What we don' t really know is why exactly the tool that you attempted using to resize/move the partition crashed/stopèped.

It is possible that there was a problem "before" that and that this problem caused the failure. :unsure:

 

jaclaz



#21
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

 

 

CHKDSK says it doesn't find any problems on either one of the partitions.

Also, I ran SFC and that said it had a few problems, should I post that log? 

 

This is strange.

I mean the autochk is connected to the *need* to run chkdsk to fix some issue (evidently of a minor kind, since that volume booted afterwards).

I would run CHKDSK /F anyway on that volume, next.

Yes, post the SFC log, though most probably those problems are unrelated.

What we don' t really know is why exactly the tool that you attempted using to resize/move the partition crashed/stopèped.

It is possible that there was a problem "before" that and that this problem caused the failure. :unsure:

I have this strange problem (probably unrelated because it started happening before) where the second OS's partition gets mapped to a letter twice (ie. E:\ and F:\ point to the same location). Would this interfere with CHKDSK in any way and does it matter which drive letter I choose?

 

Edit: I've attached the CBS.log files (SFC checker). The smaller one is the second OS. Sorry that the're zip files but my current internet connection is so bad that the normal files would just cut out and plus, I can only upload 500kb of data. 

 

I ran checkdisk and it said it found free space marked as allocated in the MFT. 

Attached Files


Edited by Torchizard, 04 November 2013 - 04:42 AM.


#22
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
My guess is that you are mixing in the same bag everything (and the kitchen sink) :w00t:
 
With the tool you used, and accordingly to your report, you did not touch the "2nd OS" volume, so each and every issue you have with that "2nd" install/OS is evidently unrelated.
 
It is actually a very good thing that you zipped those files :), as a matter of fact I always recommend to compress each and every attachment, because you send (and the board hosts) less bytes, and everyone will download less bytes, we must fight entropy and bloat, one byte at the time ;).
 
You must try to make more "exact" and "complete" reports, this "double" lettering of the same volume is "news" :ph34r:
Does this happen when you boot WHICH OS ("main" or "2nd")? (or does it happen in both)?
Which drive letters do you get when running each OS?
Do the following (booted in "main"):
  • open a command prompt
  • type in it: mountvol >mainMV.txt
  • and press [ENTER] 
reboot to "2nd OS"
  • open a command prompt
  • type in it: mountvol >2ndMV.txt
  • and press [ENTER]
Compress the two resulting files C:\mainMV.txt and C:\2ndMV.txt  into a .zip archive and attach them.
 
You did not "run chkdsk", you either run chkdsk without parameters or with the /F parameter or with the /R parameter, and you ran it from either the "main" or "2nd" OS and you got a much more accurate report that you are not reporting exactly (details are important) and you did not specify on which volume you ran it.
 
Now, provided that the volume on which the "main" OS is (the middle partition) gets drive letter D:\ (or change accordingly), when the 2nd OS is booted do exactly this:
  • boot to the "2nd" OS
  • open a command prompt
  • type in it chkdsk D: /F >mainCD.txt
  • and press [ENTER]
add the resulting file to the archive that you will attach.
 
jaclaz

Edited by jaclaz, 04 November 2013 - 05:19 AM.


#23
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

My guess is that you are mixing in the same bag everything (and the kitchen sink) :w00t:
 
With the tool you used, and accordingly to your report, you did not touch the "2nd OS" volume, so each and every issue you have with that "2nd" install/OS is evidently unrelated.
 
It is actually a very good thing that you zipped those files :), as a matter of fact I always recommend to compress each and every attachment, because you send (and the board hosts) less bytes, and everyone will download less bytes, we must fight entropy and bloat, one byte at the time ;).
 
You must try to make more "exact" and "complete" reports, this "double" lettering of the same volume is "news" :ph34r:
Does this happen when you boot WHICH OS ("main" or "2nd")? (or does it happen in both)?
Which drive letters do you get when running each OS?
Do the following (booted in "main"):

  • open a command prompt
  • type in it: mountvol >mainMV.txt
  • and press [ENTER] 
reboot to "2nd OS"
  • open a command prompt
  • type in it: mountvol >2ndMV.txt
  • and press [ENTER]
Compress the two resulting files C:\mainMV.txt and C:\2ndMV.txt  into a .zip archive and attach them.
 
You did not "run chkdsk", you either run chkdsk without parameters or with the /F parameter or with the /R parameter, and you ran it from either the "main" or "2nd" OS and you got a much more accurate report that you are not reporting exactly (details are important) and you did not specify on which volume you ran it.
 
Now, provided that the volume on which the "main" OS is (the middle partition) gets drive letter D:\ (or change accordingly), when the 2nd OS is booted do exactly this:
  • boot to the "2nd" OS
  • open a command prompt
  • type in it chkdsk D: /F >mainCD.txt
  • and press [ENTER]
add the resulting file to the archive that you will attach.
 
jaclaz

 

When I run mountvol with what you said to do, it creates a file but the file only contains what you would see if you did "mountvol /?"

I'll try to be more clear this time. A while ago, when I was getting bored with Ubuntu, I removed it from that partition and instead created a partition for data storage. Then I noticed that windows would assign two different drive letters to the same volume. Then I installed Vista and then Windows 7 (the current second OS). It has stayed like that ever since and it only shows on my main OS. When I go into Disk Management and click on "Change Drive letter and paths", it shows just E: and when I remove that letter, it does its usual busy mouse cursor thing and says F: as the letter of the partition. When I restart, it just reverts to the previous state. EDIT: I tried it again and it doesn't revert to that state anymore. It's just one driveletter now. 

 

For chkdsk, I ran it from the second OS, targeted at the main OS's partition. I ran it with the /r parameter and I've attached the output that I got before in the form of a PNG file (as it wasn't letting me copy it for some reason). When I targeted the second OS with the same parameter from the first, it said there were no problems. 

 

EDIT: I meant the /f parameter

Attached Files


Edited by Torchizard, 04 November 2013 - 06:15 AM.


#24
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,677 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

When I run mountvol with what you said to do, it creates a file but the file only contains what you would see if you did "mountvol /?"

Sure ;), and that is EXACTLY what I want to see.
Please, try again, the output of mountvol or mountvol /? is the same and after some "help" it actually lists volumes and their mountpoints:
http://ss64.com/nt/mountvol.html
If you like it better, run



mountvol | FIND "\">mainMV.txt

etc.

WHAT you weren't allowed to copy after you ran CHKDSK? The resulting file mainCD.txt?

 

jaclaz
 



#25
Torchizard

Torchizard

    Junior

  • Member
  • Pip
  • 83 posts
  • Joined 21-August 13
  • OS:Windows 7 x64
  • Country: Country Flag

 

When I run mountvol with what you said to do, it creates a file but the file only contains what you would see if you did "mountvol /?"

Sure ;), and that is EXACTLY what I want to see.
Please, try again, the output of mountvol or mountvol /? is the same and after some "help" it actually lists volumes and their mountpoints:
http://ss64.com/nt/mountvol.html
If you like it better, run


mountvol | FIND "\">mainMV.txt

etc.

WHAT you weren't allowed to copy after you ran CHKDSK? The resulting file mainCD.txt?

 

jaclaz
 

 

I ran chkdsk before I was aware that you could get it to dump output to a file so I was trying to Rclick>select all an Rclick>copy which did not work and so I just gave up and created a screenshot instead. 

 

I'll upload the mountvol output. 

Attached Files






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users