Harddisk with labeling technology build into it. (We need a "label-chip")

snipped-for-privacy@hotmail.com wrote in news:157ec44b-c576-45f9-b51a- snipped-for-privacy@googlegroups.com:

Then when you first power up your new, bare drive, get its identifier and write it down, BOY!

Then, LEARN how to find that data later, when your bloomers are in less of a bunch.

Then, IF you have a brain, when you NAME a volume you create on it, YOU might intuitively INCLUDE a familiar physical drive ID YOU enjoy using.

That way, ANY volume YOU examine will immediately tell YOU what physical drive it is also on, because YOU used YOUR two brain cells when YOU established what YOUR naming convention would be, way back when YOU actually claimed to be learning about this computing realm YOU seemed to have taken a swan dive into, without a net..

LOL.

THE RETARDNESS WITH THIS IS STRONG.

I MUST NUKE IT WITH SOME ANTI-RETARDNESS.

HERE YA GO:

HARDDISK LABEL API (INVENTED BY SKYBUCK RIGHT NOW LOL)

Pseudo Design:

GetStorageDeviceCount()

GetStorageDeviceLabel(Number)

Actual code:

var I : integer; begin

for I:=0 to GetStorageDeviceCount()-1 do begin writeln( 'Storage Device ', I, ' Label: ', GetStorageDeviceLabel(I) ); end;

end.

Doesn't need to be any more complex than that.

Slight optimization and more safe to if a device is removed during this loop or not... api implementation must be safe for that though:

var I : integer; begin

C := GetStorageDeviceCount(); for I:=0 to C-1 do begin writeln( 'Storage Device ', I, ' Label: ', GetStorageDeviceLabel(I) ); end;

end.

Bye, Skybuck.

LOL KEEP IT KISS STUPID !

Bye, Skybuck.

LOLLOLOLOLOLOLOLOLOLOLOLOLOL

WHAT VERSION WAS THIS SCRIPT WRITTEN AGAINST ?!

WHAT DOES ONE EVEN NEED TO RUN THIS LOL ?!

HOW MANY DEPENDENCIES DOES IT HAVE LOL ?!

HOW MANY TIMES WILL THIS SCRIPT BREAK.... because of new software UPDATES LOL.

YOU HAVE M?UCH TO LEARN YO:U?NG ONE... MUC?H ! LOL.

Bye, skybuck.

Gonna leave those f***ed up keyboard things in there it looks very jedi like lol.

This logic is ofcourse completely flawed cause phyisal serial numbers can still be confused as source vs dest drive or vice versa.

The only something decent solution is my solution.

To LABEL the drives:

System Backup

And then tell software to perform copy:

From: System To: Backup

Then ask:

Are you sure you want to copy system to backup drive ? Y/N.

There ya go..

Only this would make me feel somewhat safe.

Bye, Skybuck.

snipped-for-privacy@hotmail.com wrote in news:b9bf7606-5b67-4c9b-ab0c- snipped-for-privacy@googlegroups.com:

You're a goddamned retard. end

snipped-for-privacy@hotmail.com wrote in news: snipped-for-privacy@googlegroups.com:

I'd be willing to bet without even looking that all you did was copy and paste the part pertinent to your current condition, and skipped over the formating and complete report compilation code.

In other words, punk... all you are is an industry interloper, at best.

Go look that one up, punk... interloper.

While you f*ck off and die.

Better yet, HOAD!

Also some kind of "write-protect" feature for harddisks, ssd's, storage devices might be nice... like floppy disks had.

So we lost labels and we lost write-protect functionality transitioning to these new media devices.

I am not amuzed by this.

Bye for now, Skybuck.

Actually funny thing is the bigger SSD chip does have a "lock"... but not sure what the lock actually does... probably write protect lock... kinda funny.

It's very tiny easy to overlook... but I kinda knew it was there... but also easy to forget cause it's so tiny.

It's a two in one actually... the little detachable chip inside of it doesn't have the lock... so definetly lost functionality as it became tinier.

I wonder if my canon and drive actually respects the lock... gonna try it out

Yes at least windows 7 respect it funny enough ! =D

Gonna try cannon next.

It says "memory card locked"... ok so that's cool for now

Bye, Skybuck (second account cause of google posting limitations... i ll probably stop posting now see ya).

snipped-for-privacy@hotmail.com wrote in news:965fb18c-643b-468f-aa0e- snipped-for-privacy@googlegroups.com:

One single file timestamp compare would do it. And a person who actually knows what the f*ck he or she is doing.

Oh, and if you can't tell source and destination when performing a backup, you should not be the one doing it, punk. At the very least NOT UNTIL you find out the identities involved.

Sounds to me like YOU f***ed up someone's system, and now you are here barking out a bitch.

If you can't break the hardware by futzing with it, you'll f*ck it up some other way, eh?

I don't know. I don't run a Linux VM under Windoze. More commonly, I run a Windoze VM under Linux.

I don't see the connection or the reason why you insist on throwing Linux into a Windoze discussion. The original problem was identifying hard disk drives under Windoze, cloning those drives under Windoze, and possibly backing them up under Windoze. If you want to offer Linux as an alternative solution to the OP's problems, please continue.

If you do test large file copies under Windoze or Linux, and are using an SSD, you will see some interesting performance problems once your fill the SSD cache space. Start at 10:09 for "big write test": Then go back to help understand what's happening. Hint: It's not so much the software as it is the drive for large file copying.

Methinks the correct strategy for maximum speed is to use as much RAM as can be allocated for FIFO buffering and use semaphores to control the flow. Using the RAM for a VM which then allocates FIFO buffering from the RAM available to the VM, does not seem like a winning strategy. Or, more simply, use as much RAM and CPU clock cycles for moving data between the source drive and destination backup drive as possible. Some backup programs do that by booting from a flash drive or CDROM so as not to waste CPU cycle on the operating system, background programs, and anything that might consume RAM and CPU cycles best spent on the cloning or backup program.

In the distant past, I maintained a fair number of customers running various SCO products (Xenix, ODT, OSR 5, Unixware, etc). Backups were to various size QIC tape drives. I learned rather quickly that the slowest and most inefficient program available was dd. I spent considerable time optimizing block and buffer sizes, as well as experimenting with raw filesystems. Cpio and tar were useless because a 1 bit error anywhere in the file, would render the backup or copy useless. If I wanted something fast and reliable (but not cheap), I used the "super tar" programs, such as Lone-Tar and Backup Edge. Of course, hardware and software have both improved in the last 25 years, so todays programs and machines will be much faster. Meanwhile, dd has not improved much, and is still very slow.

Now, back to Windoze. This is a sample of last months image backup of my Windoze 7 C: partition. The source drive is 1 TB Seagate SATA drive. The backup destination is a Western Dismal USB3 drive. The machine is a junk HP m9077c desktop with a Core 2 Quad Q6600 CPU and

8GB of RAM. Notice that it backed up 97GB in 17:08 minutes or 5.7 GigaBytes per minute backup speed. It also compressed the backup file down to 47GB. On faster machines and using SSD drives, I've seen 10GBytes per minute and faster. That's fast enough for even the most backup resistant customer to not consider running an occasional back a major imposition on their hectic lifestyle. Note that the backup was done as an application under Windoze 7 and NOT from a bootable CD or flash drive.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

I was actually talking about when in the new Windows feature of opening a linux session. Yes, I know it is still a VM, but not like the way we used to run a Linux VM in Windows, and I was just curious and thought you might be familiar with it.

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

Pretty sure I saw the mention of "dd".

And I do not "insist" on anything. This is the first post to this thread where I reference it, and I only said it because we can now open a Linux session from within Windows, and "dd" is the de facto Linux utility for copying everything from files to volumes to drives, and my question was a curiosity as to whether Windows adds a layer of SLOWDOWN to the task, or if it gets done at some native level and is just as fast as when in a native Linux session or within windows available utilities. We used to call it "at the BIOS level" on old MFM drives because they were more intimately attached to the motherboards they ran under.

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

No shit. We are tallking about moving to a hard drive or USb which has much higher throughput numbers, not some lame old outdated tape drive system.

You have obviously no recent experience with it as you 'dismissed it' in your infinite past experience, which is always all knowing. Yeah... right.

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

Make sure it is not one of the 1TB drives they made that had a manufacturing fault.

Of all my Seagate drives over all the years, I only had one failure that was an actual hard failure, and I found out that I was not the only one. They replace though. A *very* good company. A very early player in the computer magnetic storage medium realm.

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

RAM

control

buffering

Sheesh, dude. WINDOWS VIRTUAL MEMORY. Not a MACHINE, dippy doo. Windows uses a HARD DRIVE BASED VIRTUAL RAM device. That means that YOUR perfect schema never gets used because WINDBLOWS mangles... errr manages it.

Sorry I f***ed your brain up by using the initials VM.

So LITTLE chunks get 'WRITTEN' to the WINDOWS VM FILE, BECAUSE in their infinite wisdom, they decided to NEVER use the REAL RAM in favor of their stupid drive based "RAM". So your copy operation has to take a few paths around before it actually gets buffered off onto the stick AT a rate BELOW what the stick can handle because only partial feeds are getting passed to it.

Yes, I know what happens.

No, I never suggested using a VM.