50 replies to this topic

[Wonko the Sane]

i opened the volume but where the music folder should be it still wasn't there (probably as expected). can i rebuild the structure?

If you click on "All Found+Reconstructed" it will create a "virtual file system reconstruction".

Choose at first try "Pure FS" reconstruction.

It will (should) create in the tree on the left a number of folders (eiher with "valid" names or starting with $F) that may (or may not) contain the missing files and/or folders.

 

Please understand how there is no way to know in advance if the files (if found) are good (or not), you need to extract/copy them to another device and attempt opening them.

 

Try with a few files (at random).

 

Alternatively you can try, instead of "Pure FS reconstruction" a "Full scan within the partition", this latter will atempt to find (and classify by file type) the RAW data, this option will take a lot of time to run as the whole volume will be scanned.

 

Wonko

[steveyg777]

I decided to click rebuild for structure and it brought the music folder back!
i tried recovering a sub folder and it worked!

So i decided to load up the original drive and do the same, which worked, and now in recovering all data to my spare drive. I clicked to recover meta data too (apart from the mft as i figured that the new drive would create is own record of files?) but not sure if that meta data will be useful or even needed?

Later on (of its possible to) i will do a comparison of the two sides to make sure all data was recovered and copied correctly can i do that inside dmde? Or can you recommend any free software?

The only issue i will have is that windows doesn't show anything on the drive via windows Explorer so i would need to rebuild the structure and save it. I know how to rebuild it but how do i save the new structure (obviously one I've recovered everything first)?

[Wonko the Sane]

Well, normally you verify a file by hashing (checksumming it) and comparing the result with the original checksum, but here you don' t have an "original checksum" to compare with.

 

But I am not sure about what you are asking (or what you are actually doing).

 

And no, metadata won't be of use in a file recovery like this one, let alone the $MFT.

 

The generic idea is to have a "spare drive" freshly partitoned/formatted (and visible/mounted/accessible in windows) as "target", then with DMDE right click on the files/folders that it found and "recover object" (I believe that there are some limitations in the freeware version on number of files selected or similar, but it is if I recall correctly 4000 files per folder or something like that i.e. quite "generous") and "recover to" the "target".

 

Rest assured that (unless a write error occurs - but due for other reasons) what DMDE "reads" and "extracts" is exactly the same as what you will find on the "target" once the extraction has been carried on.

 

DMDE doesn't really "reconstruct" the filesystem (in the sense that it doesn't "repair" it, it operates a "virtual reconstruction", i.e. what you see in DMDE is accessible only from DMDE.

 

Once you have recovered every file you can you can try running on the "original" disk drive a set of three runs of CHKDSK (running on a suitable Windows NT operating system, let's say Windows 7), please FORGET what you may have read elsewhere, run CHKDSK (and NOT any other program) in three runs (and EXACTLY as suggested):

1. CHKDISK <drive letter> (with NO parameters)

2. CHKDSK <drive letter> /F

3. CHKDSK <drive letter> /R

 

It may happen that it succeeds to rebuild the filesystem correctly (and thus you have all or most of the data back on the original disk) or it may not.

 

Wonko

[steveyg777]

Yeah you understood me ok. Just reading what i wrote i didn't realise there were so many text prediction errors. I wrote it quickly via my iPhone this am you see. Stupid thing!

Us i will do all of this methodically.

I'll let you know what happens

[steveyg777]

I am trying to recover the files into a folder called root and it keeps asking me about renaming the files otherwise it can't copy them. I understand this as there is a limit to the path and name of files. So i selected all the files within the folder instead so that it would recover them to the root of the spare drive (without the extra folder called root) but it asked me about renaming again! This is a big concern because i don't want files missed or messed around with if the names are changed etc. Do you think i have a parameter set wrong or something that will make this ok?

[Wonko the Sane]

Well, if you have paths exceeding 260 characters Windows will choke on them (this is a known issue and may be part of the reason why the original move command made a mess).

You can try using a UNC path as destination:

\\?\<drive letter>:\root\

 BUT it depends on the actual functions used by the tool(s) involved, if they use the non-UNC version it won't work:
https://msdn.microso...7(v=vs.85).aspx

 

However IF you have paths longer than 260 characters you are what in jargon we highly specialized technicians call "looking for troubles" .

 

Post the name and path of a few example files that gives you the problem, you might be able to shorten them keeping the filenames but using shorter directory names, if an actual filename is longer than 256 characters you will need to rename it.

The most you can do is to use SUBST to map (say) D:\root\ to Z:\ saving 4 characters.

 

Wonko

[steveyg777]

Ok well I'm recovering at the moment and is taking days! Probably gonna be at least another for days (!) averaging copying at about 11mb/s lol. Is a very slow app heh?

I'll keep you posted though

[steveyg777]

Wow this path length limit is such a pain in the a$$!!!!

I am still trying to recover stuff and is gotten messy because I've had to move sub folders to the root in order to recover files to them and now i have to remember where they came from. Really tempted to delete the music folder and re recover using that \\?\ thing!

I found an app that will let me check path lengths later on so i can make sure no paths exceed the limit after organising things better :

https://pathlengthchecker.codeplex.com

Hope that helps people

[steveyg777]

Hi Wonko,

 

How are you?

 

Well the result so far is that i did a full scan of the drive, opened a reconstructed version of thje disk up in dmde and recovered as much as possible off the drive. there werent many files that it "found" (as in ones already deleted) but it found the music folder that had gone missing in a subfolder.

 

after recovering i now only have 100gb free on the second drive (a 5tb HDD too) where as the original drive only has about 5gb free so either some files dont seem possible to find or the drive was so fragmented that it had wasted that extra 95gb in storing files inefficiently, or something else expains it. what do you think?

 

I did the chkdsk (without anything and also with the /f command) and here is what came up:

 

C:\WINDOWS\system32>chkdsk z:
The type of the file system is NTFS.
Volume label is Seagate Backup Plus 5Tb Drive.

WARNING!  /F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
  2723357 file records processed.
File verification completed.
  2120 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
Error detected in index $I30 for file 5.
Error detected in index $I30 for file 5.
Error detected in index $I30 for file 5.
Error detected in index $I30 for file 538824.
  3649479 index entries processed.
Index verification completed.

Errors found.  CHKDSK cannot continue in read-only mode.

C:\WINDOWS\system32>chkdsk /f z:
The type of the file system is NTFS.
Volume label is Seagate Backup Plus 5Tb Drive.

Stage 1: Examining basic file system structure ...
  2723357 file records processed.
File verification completed.
  2120 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
Correcting error in index $I30 for file 5.
Correcting error in index $I30 for file 5.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 5.
Sorting index $I30 in file 5.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 538824.
  3649479 index entries processed.
Index verification completed.
  0 unindexed files scanned.
  0 unindexed files recovered to lost and found.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Inserting data attribute into file 1207500.
Inserting data attribute into file 2706465.
Inserting data attribute into file 2707704.
Inserting data attribute into file 2707705.
Inserting data attribute into file 2708215.
  463066 data files processed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
Correcting errors in the Volume Bitmap.

Windows has made corrections to the file system.
No further action is required.

   4769299 MB total disk space.
   4752443 MB in 2710743 files.
    437000 KB in 463063 indexes.
         0 KB in bad sectors.
  11067040 KB in use by the system.
     65536 KB occupied by the log file.
   5756032 KB available on disk.

      4096 bytes in each allocation unit.
1220940596 total allocation units on disk.
   1439008 allocation units available on disk.

 

I checked the drive afterwards and the folder did not reappear where it was originally located. thinking about it though i forgot to check where dmde placed it after scanning (within a subfolder) and im now doing the chkdsk scan with /r command so will have to wait (i don't personally think it will find any bad sectors though)

 

just keeping you posted

 

thanks for your help.

 

is there any software that can rebuild the file structure permanently (like dmde rebuilt it)?

 

i was going to try an app called "testdisk" but each time i load it my computer completely freezes! :/

[Wonko the Sane]

I checked the drive afterwards and the folder did not reappear where it was originally located. thinking about it though i forgot to check where dmde placed it after scanning (within a subfolder) and im now doing the chkdsk scan with /r command so will have to wait (i don't personally think it will find any bad sectors though)
 
just keeping you posted
 
thanks for your help.
 
is there any software that can rebuild the file structure permanently (like dmde rebuilt it)?
 
i was going to try an app called "testdisk" but each time i load it my computer completely freezes! :/

The point here is whether the "original move" of the folder was completed or not.
Moving a folder (and all its subfolders) on a "same" filesystem should be very fast as only pointers are changed, but what is likely to have happened is that there were some "previous issues" in the filesystem (possibly even minor ones) and the "move" operation choked on these issues.
 
Testdisk is useful for partition recovery (not filesystem checking/veryfying), there is a "companion tool" Photorec that can recover files (not entirely unlike what DMDE did) but - just like DMDE - it will only allow to copy files to another filesystem/drive.
If you prefer, what (IMHO) created the major issue was the check of the filesystem with a non-native tool, it is very possible that now CHKDSK has fixed all the issues (of course with the folder "moved") i.e. the "original drive" once chkdsked might provide you full access to everything, but - see below - it is also entirely possible that the $Logfile and/or other transaction logs had not enough space on disk.
 
You raise another interesting point with your:

after recovering i now only have 100gb free on the second drive (a 5tb HDD too) where as the original drive only has about 5gb free so either some files dont seem possible to find or the drive was so fragmented that it had wasted that extra 95gb in storing files inefficiently, or something else expains it. what do you think?

There are 3 (three) rules of thumb with NTFS:
1) NEVER (and I mean NEVER) run anything but a suitable version of CHKDISK in case of filesystem issues
2) NEVER use path/names longer than 260 characters <- less strict than the above, but a good idea anyway
3) DO NOT fill a NTFS volume "up to the brim" <- ideally a NTFS volume should always have some 5% of free space (used to be 10 to 15% of capacity), a "data only" and "very big" volume might be good with less, let's say 1%, but 5 Gb free on a 5 Tb volume is like 0.1%, it may well be enough, still ...

I thought till now that you failed in two out of three, now I see how you got all three.


Wonko

[steveyg777]

C:\WINDOWS\system32>chkdsk /r z:
The type of the file system is NTFS.
Volume label is Seagate Backup Plus 5Tb Drive.

Stage 1: Examining basic file system structure ...
  2723357 file records processed.
File verification completed.
  2120 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
  3649479 index entries processed.
Index verification completed.
  0 unindexed files scanned.
  0 unindexed files recovered to lost and found.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
  463061 data files processed.

Stage 4: Looking for bad clusters in user file data ...
  2723341 files processed.
File data verification completed.

Stage 5: Looking for bad, free clusters ...
  1439005 free clusters processed.
Free space verification is complete.

Windows has scanned the file system and found no problems.
No further action is required.

   4769299 MB total disk space.
   4752443 MB in 2710744 files.
    436996 KB in 463063 indexes.
         0 KB in bad sectors.
  11067044 KB in use by the system.
     65536 KB occupied by the log file.
   5756020 KB available on disk.

      4096 bytes in each allocation unit.
1220940596 total allocation units on disk.
   1439005 allocation units available on disk.

 

as i thought

[Wonko the Sane]

Yep  the disk (hardware) is fine (no bad sectors).

1,439,005x4,096=5,894,164,480=5,756,020 Kb so yes, it is confirmed around 5 Gb of free space.

 

Wonko

[steveyg777]

Ok thanks for your Wonko.After

 

deciding that I could not get naymore data off the original drive I formatted it wiht the intention of using it as a backup of the second drive from now on.

 

Here comes the next huge hurdle!

 

the second drive is formatted as follows:

 

NTFS Version   :                   3.1
LFS Version    :                   1.1
Number Sectors :                   0x00000002462ccfff
Total Clusters :                   0x0000000048c599ff
Free Clusters  :                   0x00000000004c6dc8
Total Reserved :                   0x0000000000000010
Bytes Per Sector  :                512
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x00000000ab700000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x00000000000ab0e0
Mft Zone End   :                   0x00000000000ac080
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0x0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     877C7C54-2B7F-11E6-A243-C86000C62CAD

 

 

BUT the original drive is now formatted as follows:

 

NTFS Version   :                   3.1
LFS Version    :                   1.1
Number Sectors :                   0x0000000048c599ff
Total Clusters :                   0x0000000048c599ff
Free Clusters  :                   0x000000004708be5d
Total Reserved :                   0x0000000000000000
Bytes Per Sector  :                4096
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  4096
Clusters Per FileRecord Segment :  1
Mft Valid Data Length :            0x000000001b600000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x00000000015d14a0
Mft Zone End   :                   0x00000000015ddcc0
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0x0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     35F397A7-3C77-11E6-A24A-C86000C62CAD

 

 

i have been looking on the internet about the whole issue with backing up to/cloning to drives with different sector sizes but just don't have the time to figure out the answer, do you know? the best i found as a solution is to use a WD factory formatter app but only works with WD drives not seagate

 

macrium reflect and a few other apps either bring up an "different sector size" error or don't let me choose the original drive as the destination. I want to clone the drive as opposed to make an image so that all files are instantly accessible.

 

Is this possible?

[Wonko the Sane]

Is this possible?

Normally no.

That is almost the whole "mess" between AF (Advanced Format) and "Native 4k" drives, BUT the issue may (or may not) lie in the USB external case/adapter vs. direct connect.

Have a quick look here:

http://reboot.pro/to...dge-in-the-mix/

 

Basically:

1. a "traditional" disk has has internally 512 bytes  sized sectors AND exposes externally 512 bytes ones sized sectors <- FIXED, no problem normally AND it cannot be your case given the large size of the disks at hand

2. an AF disk has internally 4 Kb sized sectors BUT should expose externally 512 bytes ones (for compatibility reasons). <- may be variable depending on disk and interface

3. a "native 4k" has internally 4kb sized sectors AND exposes externally 4 kb sized sectors.<- FIXED, no problem normally

 

In your case "second drive":

Bytes Per Sector : 512
Bytes Per Physical Sector : 4096

is seen as AF, 

 

whilst "original drive":
Bytes Per Sector : 4096
Bytes Per Physical Sector : 4096

is seen as "Native 4k".

 

If both disk drives are "directly connected" it means that they are - respectively - an AF and a Native 4k (and there is nothing you can do).

If both disk drives are inside a USB case (or anyway use a USB converter) it is possible that one is AF and the other one is an AF "masked" as Native 4K by the USB controller.

 

If one is USB, one is direct connect, you may be in the situation in the mentioned thread

 

One would need to physically open the USB case and check exact model of the hard disks inside to know more.

 

Wonko

[steveyg777]

i checked the link you gave me and, apart from maybe looking promising?, I don't really understand all the geek involved on it. is that zip file worth downloading and can i use it for my purposes to make both drives show up the same?

[Wonko the Sane]

i checked the link you gave me and, apart from maybe looking promising?, I don't really understand all the geek involved on it. is that zip file worth downloading and can i use it for my purposes to make both drives show up the same?

NO, I don't advise it.

That was a workaround to solve a specific issue and though it works fine in that scenario it won't work in yours and anyway won't allow you to do what you want, i.e. to do a clone operation.with a "smart" tool.

 

If the devices are seen with a different geometry (sector size) it cannot be done by one of those programs.

 

As often happens we must somehow agree on what is a "clone".

A "real clone" is a sector by sector, byte by byte copy.

 

What is maybe theoretically possible to do in your case[1] is to use a "simple" (as opposed to "smart") dd-like program and make an exact copy (i.e. a clone)[2].

This copy won't be functional, but it can be modified (a few values need to be changed) to make it functional (but then it won't be a clone anymore, it will be very, very similar, but not a clone).

Now the geekish part.

The filesystem (NTFS) created when the volume is formatted uses:

1. on 512 bytes sector disks a $MFT entry size of 1024 bytes (aka two sectors )

2. on 4096 bytes sector disks a $MFT entry size of 4096 bytes (aka one sector, minimum addressable unit)

 

The size of the $MFT entry is however a field in $Boot (the VBR) so that even if the default size on 512 bytes disk is 1024, the 4096 is perfectly valid.

As well the default size for a cluster is usually 4096 bytes anyway (and it is another field in $Boot).

 

So the differences are the addresses (LBA) in the partition table and the "number of sectors before" and "total sectors" fields in the $Boot.

 

All that is needed is to take the valid values from the 4096 bytes disk and multiply them by 8 on the 512 bytes disk.

 

The issue here is that a larger than 2 Tb 4096 bytes disk can well be partitioned MBR style (I believe), whilst a AF disk cannot (and it *needs* GPT).

 

We have to understand if the original is also GPT and if editing of the GPT partition table on the "target" is doable (I believe it is, but has to be verified).

 

We can still have the "original" MBR and the "target" GPT but it will be a tad bit more difficult, and it won't again be a "clone".

 

Instead of cloning the disk, we could maybe clone the volume, since even now the sizes are the same:
Number Sectors : 0x00000002462ccfff /8= Number Sectors : 0x0000000048c599ff

And only change the "total sectors" number in the $Boot (and if needed the "sectors before").

 

Wonko

 

 

[1] It is possible in your case because the "original" has 4096 bytes sectors and the "target" has 512 (the opposite would be impossible)

[2] but since the disk size is above the 2.2 Tb "limit", I don't know what could happen (different Operating Systems might well behave differently) unless the disk is partitioned "GPT Style".

[steveyg777]

Yes i can confirm that i formatted the second drive (that now has all my files on) as gpt.i needed to do this for both in order to get passed the 2.2tb boundary. This second drive is the one with 512 format. That's still ok right? (You said it wasn't possible one way around).

I have to say though that this is disgraceful that people have to screw around so much may to use their flippin drives! :/

[Wonko the Sane]

Yes i can confirm that i formatted the second drive (that now has all my files on) as gpt.i needed to do this for both in order to get passed the 2.2tb boundary. This second drive is the one with 512 format. That's still ok right? (You said it wasn't possible one way around).

I have to say though that this is disgraceful that people have to screw around so much may to use their flippin drives! :/

Yep, it sucks (BIG).

But yes it is OK, only you won't be able to literally "clone" it.

 

I need some more geektalk.

 

The MBR and the GPT are not that much different (the first is "simple", the second is needlessly complex) but ultimately all they do is to provide infos to the OS on where a volume starts and on how many sectors are in the volume.

 

The MBR scheme is limited by having 32 bit fields. i.e. 8 bytes, i.e. anything bigger than 0xFFFFFFFF won't be accurate.

Since 0xFFFFFFFF = 4294967295 you cannot address more than those sectors, i.e. 4294967295*512=2199023255040 bytes or, in the case of "native" 4096 4294967295*4096=17592186040320 bytes.

 

GPT instead uses "wider" fields, 64 bit ones or 16 bytes, then  0xFFFFFFFFFFFFFFFF=18446744073709551615 allows for a lot of sectors, much more than any existing device (and also foreseeable in the immediate future for customer use) will be able to contain.

So, the 5Tb "native" 4kb can well be MBR, but the same 5Tb AF (512 bytes/sector exposed) cannot be but GPT.

 

The NTFS filesystem on the other hand was written by someone who actually knew where his towel was, and since day 0 (we are talking 1992 here) it uses 64 bit wide fields for the "size" fields AND it has a field to specify bytes per $MFT entry.

 

In your case, the partitioning of the 4096 bytes/sector and the partitioning of the 512 byte/sector disks gave birth to a single NTFS volume (primary partition) of exactly the same size, so it is possible to "almost clone" a NTFS volume which has been created on th 4096 bytes/sector device and have it working on a 512 bytes/sector device by modifying only a few fields in the VBR or $Boot.

 

If you want to try doing this, let me know and I will guide you through the procedure, there isn't AFAIK a "pre-made" automated tool that does this automagically since it is an "edge" or however "rare" case.

 

Wonko

 

[steveyg777]

Yes I'd like to do this.please give me the directions

Is there any chance of the disk corrupting sure to modifying these things or is it only add likely as a normal format and will all systems (mac as well) recognise and "play ball" with this drive?

[Wonko the Sane]

Yes I'd like to do this.please give me the directions

Is there any chance of the disk corrupting sure to modifying these things or is it only add likely as a normal format and will all systems (mac as well) recognise and "play ball" with this drive?

 
I don't think there can be any issue, it is perfectly "legit" to have a NTFS filesystem with a $MFT record size of 4096 bytes (even on a device with 512 bytes sectors) and this has been tested (on MS Operating Systems like XP, 7 and 8/8.1) it is possible however that the good Apple guys (or however anyone non MS have implemented their filesystem driver without taking into account this possibility.
It shouldn't have happened, but it is possible.
 
Since (by pure chance) you have seemingly exactly the same volume size on both the 4096 and 512 bytes device, all is needed is to dd the volume extents with the 4096 bytes device as source and the 512 bytes device as target, then correct a couple fields in the $Boot.
 
Are you familiar with dd (or similar raw copying programs)? Which one are you planning to use?
 
Are you familiar with a hex/disk editor?
Get TinyHexer (yeah I know it's old but should work fine on 7):
http://www.softpedia...iny-hexer.shtml
it has a simple template system that will help changing the fields, DMDE can also be used, but it is more difficult to use for this editing (while it might be easier to use to backup the VBR/$Boot)
 
Run Tiny hexer.
Open with it FIle->Disk->Open Drive
The partition on the 4096 disk (it will be something *like* \\.\D:\(Physicaldrive1, partition1).
The D:\ above is the same drive letter you see in Windows for that drive.
Make sure that the Bytes/Sector column reads 0x1000=4096 
Make sure that at the bottom dialog is (autofilled) 0x01.
A single sector will be opened, now:
File->Save as and save it to a file (on another disk), call it (let's say) my4096boot.dat, the file will be 4096 bytes in size.
Repeat the same for the 512 disk, but:
Make sure that the Bytes/Sector column reads 0x200=512
Make sure that at the bottom dialog is (autofilled) 0x01.
A single sector will be opened, now:
File->Save as and save it to a file (on another disk), call it (let's say) my512boot.dat, the file will be 512 bytes in size.
You should have the two saved files still open.
Now run Tools->Compare->Compare
Tiny hexer will warn you that one file is larger than the other (ignore this, we know that).
Now you should have highlighted the differences between the two.
Select (click on) one of the two windows.
Then Tools->Structure Viewer->Choose NTFS boot structure.
If you click on any underlined field in the structure viewer, you will see the corresponding area on the hex dump selected.
Most fields will be the same, BUT:
Sectors per cluster will be respectively 1 and 8
The fields marked "Not used by NTFS" will likely be different (will get  to them later)
Total sectors will be different and the second will be 8 times the first.
Bytes per $MFT record will be different and will be respectively 4096 and 1024.

Try doing the above as an exercise to get familiar with the program, then I will give you some instructions for using the "duplicating" program you choose or suggest one to you.


Wonko

[steveyg777]

Hi wonko. Sorry for no reply i have had a busy time and won't be free to follow your guide through until the end of next week to be honest. I have a lot of things that need my attention urgently currently but when I'm free I'll get back to you

[Wonko the Sane]

Hi wonko. Sorry for no reply i have had a busy time and won't be free to follow your guide through until the end of next week to be honest. I have a lot of things that need my attention urgently currently but when I'm free I'll get back to you

I don't think anyone is after you , surely noone is after me. (I know, I checked in the rear mirror ).

 

Seriously , no need to be sorry or to apologize for being busy, there is no hurry whatever, after all it is just an experiment, but thanks for keeping me updated.

 

Wonko

[steveyg777]

Hi. After giving this a think through again i have decided to just copy all the files to a mac formatted hfs plus drive to become the used drive (the original one).after this i will format the drive, i initially cloned the data to, to hfs plus too and copy the files back - unless there is a way of converting the format workout having to reformat and re copy???

Thanks for your expertise though mate

Steve

[Wonko the Sane]

No, iI don't think that anything exists capable of converting a NTFS filesystem to HFS (and even if it existed, personally I wouldn't trust it on a filled volume).

 

Reformatting and copying over might take a little more time but definitely it is the "right thing" to do.

 

Anyway the positive outcome of your ordeal has been that you will have in the end a backup of the data (which is what everyone should have if he/she cares about the data) .

 

Wonko

[steveyg777]

Yeah. I am gonna try out an app that I've found first though, although I'll have to use it on my pc cos it's windows only (the mac version doesn't have the feature).

http://www.paragon-s...l/features.html

It can convert the file system between ntfs and hfs. There's also a stand alone version of the app and both are free!

http://www.paragon-s...-hfs-converter/

I'll check the drive afterwards and if it isn't quite right I'll do the long "format and re copy" method. Again thank you so much for your help wonko. It is much appreciated