Cannot access new Seagate external HD

Terry Pinnell wrote:

I've just added another, a Seagate 'Expansion' 2 TB 3.5" desktop HD (£60).
I later found that MBR can 'only support drives under 2 TB'.

Wrong. The partition records (4 of them) in the MBR's partition table
can each handle up to 2 TB *partitions*. With 4 partition records, you
can create up to 4 primary partitions. If one of them is a extended
partition, you can create multiple drives within that partition. Drives
are letter designations given to partitions (or volumes if you span).
The maximum partition for a partition record is NOT the maximum size of
the disk.

You have a 2 TB drive. The max size for a partition on it is 2 TB, the
same maximum supported by MBR partition records.

If you bought a 4 TB disk, you could create two 2 TB partitions.
If you bought a 6 TB disk, you could create three 2 TB partitions.

Mike Tomlinson wrote:

En el artículo , Terry
Pinnell escribió:

Spent a
couple of hours on it so far, but reckon I'll parcel it up ;-(

Don't do that Terry. You'll have to pay to send it back. Maybe someone
from here could do it via remote desktop while you watch (and learn),

The DISKPART command you need is 'list disk'.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\mikediskpart

Microsoft DiskPart version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: XXXXXX

DISKPART list disk

Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 238 GB 0 B
Disk 1 Online 238 GB 0 B
Disk 2 Online 1863 GB 1024 KB


Thanks Mike. Yes, it proved simple enough to use once I'd found those
Seagate instructions. (A tad crucial to get the disk number right!)

Perhaps I'm worrying unnecessarily, but the following puzzles me...

I immediately started an overnight copy from K: (the slightly suspect
6-year old drive) to F: (the new, precautionary Seagate 2 TB). I was
surprised to see this message on my screen this morning:
https://dl.dropboxusercontent.com/u/...eTooLong-1.jpg

And I'm pretty sure the run had stopped. (I need to re-test later when
I have this major copy finished; status wasn't immediately obvious.)
But, that aside, I don't understand the message. Why should a folder
name of only 33 characters generate an error? And it wasn't being
asked to 'remove' it.

Anyway I then re-started the copy (on the largest subfolder this time)
and soon got another message:
https://dl.dropboxusercontent.com/u/...NotEmpty-1.jpg

Apart from that 'remove' again, it doesn't seem to make sense. The
great majority of folders are none-empty!
FWIW, here's what the source looks like:
https://dl.dropboxusercontent.com/u/...NotEmpty-2.jpg


Excuse the switch of topic, but I'd appreciate any recommendations for
a 2 (or 3) TB desktop HD that IS a no-brainer installation on an XP
Pro PC please. And ideally one that doesn't spin down, as that's been
causing problems with my 2 TB WD.

The one you have is almost certainly fine. To wipe the odd GPT
partition(s), you can use CLEAN in DiskPart. Type HELP CLEAN for the
syntax. Once you have done this you should be able to create a standard
MBR partition table, then create a partition and format it.

Delivery was free and refund was in full, so I'd have been OK on that
score, but I've cancelled the return now. Just in time it seems, as
DPD were on the way. Email at 21:57 last night: "Your Amazon parcel/s
will be collected 11 September by DPD between 09:00-18:00."
Kudos to Amazon ;-)

--
Terry, East Grinstead, UK

micky wrote:

In comp.sys.ibm.pc.hardware.storage, on Thu, 10 Sep 2015 19:20:30 +0100,
Terry Pinnell wrote:


As you see, I cannot access the drive. It's shown in Device Manager
and Disk Management - but as you see it has no letter, nor can I do
anything about it. A 'GPT Protective Partition' has been set up,
whatever that is,

That's a Grinstead Protective Treament. It's meant to protect the
drive until you use it. It's somethin glike the clear vinyl sheet on
camera and cellphone screens when you buy a new one.

and I cannot remove it.

Very good - I glike it.

I'll get a jar and start applying it regularly ;-)

--
Terry, East Grinstead, UK

In article , Terry Pinnell
wrote:
And anyway, I later found that MBR can 'only support drives under 2
TB'.

That's not absolutely correct. If you want the whole story, MBR can
only support drives that have 2^32 or fewer blocks, and as a block is
traditionally 512 bytes that means the biggest disk you can have is
2TB.

... or, strictly, that you can use a bigger disk but only put
partitions on the first 2TB of it.

But, if you're using an OS that can work with disks whose blocks are
bigger than 512 bytes you can use all of a bigger disk and still use
MBR. [Note that although a lot of modern disks internally use a 4k
physical sector, they typically then pretend that the sectors are only
512 bytes, so that's what the OS sees ... and you're back to the 2TB
limit.]

The 512-byte sector size is so pathologically hard-coded into Windows
that you can't change it. Linux can support different physical sector
sizes, so you could probably make MBR work on a large disk, but I
wouldn't expect all disk management tools to run correctly because that
512 byte value must be (erroneously) baked into an awful lot of
sourcecode.

However, the disks you've purchased are not bigger than 2TB, so MBR
will handle them just fine. It's just that they've been pre-partitioned
with GPT. You only have to wipe them and repartition.

Note that under the GPT scheme there is a boot record at the start of
the disk (as usual) and also a backup copy of the partition table at
the far end of the disk. UEFI firmware may refuse to allow you to use
the disk as MBR while either of those exists, so you need to wipe both
of them before repartitioning the disk as MBR.
--
Cheers,
Daniel.

In article , Terry Pinnell
wrote:
I immediately started an overnight copy from K: (the slightly suspect
6-year old drive) to F: (the new, precautionary Seagate 2 TB). I was
surprised to see this message on my screen this morning:
https://dl.dropboxusercontent.com/u/...eTooLong-1.jpg

I think Windows is complaining about the full pathname being too long,
not just the name of the file within the directory.

And it wasn't being asked to 'remove' it.

Are you using a "move" command to copy these files to the new drive?
That will mean that Windows has to copy the files and then delete them
from the old drive. It looks like the "copy" part has worked, but (for
some reason known only in Redmond) the "delete" part specifies the
filename in a different way (absolute rather than relative path) and so
fails.

Anyway I then re-started the copy (on the largest subfolder this time)
and soon got another message:
https://dl.dropboxusercontent.com/u/...NotEmpty-1.jpg

Again, this seems to be because you're doing a "move", so the old files
have to be deleted. Windows is complaining that it can't delete that
directory because it isn't empty. If that was the folder that contained
the file that wasn't deleted because of the "filename too long" thing,
then that's your reason. Otherwise there's some other file in that
directory that wasn't deleted ... for some unknown reason. Maybe
permissions? Maybe a file with alternate data streams?

--
Cheers,
Daniel.

In article , VanguardLH wrote:
I've just added another, a Seagate 'Expansion' 2 TB 3.5" desktop
HD (£60).
I later found that MBR can 'only support drives under 2 TB'.

Wrong. The partition records (4 of them) in the MBR's partition table
can each handle up to 2 TB *partitions*.

That's sort-of true, in an unuseful sort of way. Any one of those four
slots could describe a 2TB partition, but you can't use them all.

Each slot contains the start position of the partition as a 32-bit
number denoting the first sector's LBA, and the size of the partition in
sectors.

It has been suggested that you could have two 2TB partitions on a 4TB or
bigger disk by creating on partition at sector 2 with a size of FFFFFFFD
(so, ending at FFFFFFFE) and another starting at FFFFFFFF with a length
of FFFFFFFF (so ending at 1FFFFFFFE) -- that would describe the
partitions accurately, so in a sense you can.

However, the code that manipulates sector numbers in an OS is very
likely to use 32-bit numbers, so the top bit on any sector number in the
second partition would be lost, and the result would be that data was
read from and written to the wrong place. You could probably make it
work with a specially constructed device driver, but going to GPT is a
better, safer, and more future-proof way.

If you bought a 6 TB disk, you could create three 2 TB partitions.

Not with MBR and 512-byte sectors, you couldn't. There's just no way to
specify that the third partition starts at 200000000 (hex) in a single
32-bit number.

--
Cheers,
Daniel.

On Fri, 11 Sep 2015 07:16:34 +0100, Terry Pinnell
wrote:

Mike Tomlinson wrote:

En el artículo , Terry
Pinnell escribió:

Spent a
couple of hours on it so far, but reckon I'll parcel it up ;-(

Don't do that Terry. You'll have to pay to send it back. Maybe someone
from here could do it via remote desktop while you watch (and learn),

The DISKPART command you need is 'list disk'.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\mikediskpart

Microsoft DiskPart version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: XXXXXX

DISKPART list disk

Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 238 GB 0 B
Disk 1 Online 238 GB 0 B
Disk 2 Online 1863 GB 1024 KB


Thanks Mike. Yes, it proved simple enough to use once I'd found those
Seagate instructions. (A tad crucial to get the disk number right!)

Perhaps I'm worrying unnecessarily, but the following puzzles me...

I immediately started an overnight copy from K: (the slightly suspect
6-year old drive) to F: (the new, precautionary Seagate 2 TB). I was
surprised to see this message on my screen this morning:
https://dl.dropboxusercontent.com/u/...eTooLong-1.jpg

And I'm pretty sure the run had stopped. (I need to re-test later when
I have this major copy finished; status wasn't immediately obvious.)
But, that aside, I don't understand the message. Why should a folder
name of only 33 characters generate an error? And it wasn't being
asked to 'remove' it.

Anyway I then re-started the copy (on the largest subfolder this time)
and soon got another message:
https://dl.dropboxusercontent.com/u/...NotEmpty-1.jpg

Apart from that 'remove' again, it doesn't seem to make sense. The
great majority of folders are none-empty!
FWIW, here's what the source looks like:
https://dl.dropboxusercontent.com/u/...NotEmpty-2.jpg


Try doing the backup from a USB-Linux-booted OS. I sometimes
have trouble with torrents that download files with "illegal chars". I
have to boot to Linux and rename them so I can move them around.
Or it could be that the old HD is corrupting the files. In
which case, backup ASAP.
PS I hope you are copying those files, and not moving them.
Moving files from a problematic disk that is in use is a sure way of
making them unrecoverable if the disk crashes, as a lot will be
overwritten by newer files(logs etc).
[]'s

--
Don't be evil - Google 2004
We have a new policy - Google 2012

On Fri, 11 Sep 2015 07:16:34 +0100, Terry Pinnell
wrote:

Perhaps I'm worrying unnecessarily, but the following puzzles me...

I immediately started an overnight copy from K: (the slightly suspect
6-year old drive) to F: (the new, precautionary Seagate 2 TB). I was
surprised to see this message on my screen this morning:
https://dl.dropboxusercontent.com/u/...eTooLong-1.jpg

And I'm pretty sure the run had stopped. (I need to re-test later when
I have this major copy finished; status wasn't immediately obvious.)
But, that aside, I don't understand the message. Why should a folder
name of only 33 characters generate an error? And it wasn't being
asked to 'remove' it.

You have to also take into account the entire length of the path. If this 33
character object is in the root directory, then no problem, but if it's
buried deep enough that the entire path spec exceeds the system limit, then
you'll get this error. Rename one or more parent folders until the path is
short enough to be valid.

En el artículo , Mark
Perkins escribió:

You have to also take into account the entire length of the path. If this 33
character object is in the root directory, then no problem, but if it's
buried deep enough that the entire path spec exceeds the system limit, then
you'll get this error. Rename one or more parent folders until the path is
short enough to be valid.

That's one way to do it, or you can bypass the path length limitation of
the shell and address the file directly using the command line. The
filesystem has a longer maximum path length than the shell. To access a
file with a pathname too long for the shell to cope with, use the prefix
\\?\. This bypasses the shell and sends the command directly to the
filesystem.

Example: you want to delete a file, fred.txt, buried at the bottom of
several dozen subdirectories. Explorer won't touch it because the full
path is too long. Instead, from a command prompt:

del \\?\c:\some\impossibly\long\path\with\loads\of\sub folders\fred.txt

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

Daniel James wrote:

In article , Terry Pinnell
wrote:
And anyway, I later found that MBR can 'only support drives under 2
TB'.

That's not absolutely correct. If you want the whole story, MBR can
only support drives that have 2^32 or fewer blocks, and as a block is
traditionally 512 bytes that means the biggest disk you can have is
2TB.

.. or, strictly, that you can use a bigger disk but only put
partitions on the first 2TB of it.

But, if you're using an OS that can work with disks whose blocks are
bigger than 512 bytes you can use all of a bigger disk and still use
MBR. [Note that although a lot of modern disks internally use a 4k
physical sector, they typically then pretend that the sectors are only
512 bytes, so that's what the OS sees ... and you're back to the 2TB
limit.]

The 512-byte sector size is so pathologically hard-coded into Windows
that you can't change it. Linux can support different physical sector
sizes, so you could probably make MBR work on a large disk, but I
wouldn't expect all disk management tools to run correctly because that
512 byte value must be (erroneously) baked into an awful lot of
sourcecode.

However, the disks you've purchased are not bigger than 2TB, so MBR
will handle them just fine. It's just that they've been pre-partitioned
with GPT. You only have to wipe them and repartition.

Note that under the GPT scheme there is a boot record at the start of
the disk (as usual) and also a backup copy of the partition table at
the far end of the disk. UEFI firmware may refuse to allow you to use
the disk as MBR while either of those exists, so you need to wipe both
of them before repartitioning the disk as MBR.

Thanks. As per my subsequent post, drive is now fully accessible after
using DISKPART to do as you suggest.