English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   project.Green Amiga Alien GUIDES (https://eab.abime.net/forumdisplay.php?f=59)
-   -   Why HDF for a Workbench setup? (https://eab.abime.net/showthread.php?t=28277)

Kodoichi 28 February 2007 09:11

Why HDF for a Workbench setup?
 
Paul, in the Workbench 3.1 tutorial, why do you suggest creating a HDF with limited space? Creating folders in Windows, then assigning WinUAE to it is simple and doesn't limit space :confused

Mad-Matt 28 February 2007 11:45

why not ? no risk of incompatible file names and locked files with a hdf file and dont need to much free space on a workbench drive anyway.

Marcuz 28 February 2007 14:07

i remember having had problem with hdir workbenches with earlier Winuae versions, specifically with Aiab and ClassicWB. so i switched to HDFs.
their downside is the possible loss of datas with some version of Winuae (it happened recently with betas); so it's smart to have backups.

however, in 5 years of use, i would say HDFs have become more reliable and they are the best solution for the main hard disk to me. they are also easily movable and archivable.

Mad-Matt 28 February 2007 14:23

did the betas destroy the hd file, or was it just unreadable for a while until fixed ?

Toni Wilen 28 February 2007 14:26

No data loss, first few betas only wrote incorrect hdf configuration when saving config file.

Marcuz 28 February 2007 16:11

yeah sorry, not exactly data loss: i don't remember the correct number of the beta, it was one of the firsts of the last month, i got a couple of unvalidated harddisk HDF when switching to it, solved by using the tools with ClassicWB
however no data loss really.

it's some year since winuae did break me hdfs.

Anubis 02 March 2007 17:53

Quote:

Originally Posted by Kodoichi
Paul, in the Workbench 3.1 tutorial, why do you suggest creating a HDF with limited space? Creating folders in Windows, then assigning WinUAE to it is simple and doesn't limit space :confused

In some cases it is windows limitation as amiga install can include way to many files and widnows can have limit on number of files in direcotry if I remember correctly.

Also, amiga can have files without file name if I remember correctly. (or was it spaces instead of name?) :confused

HDF is better IMHO.

Toni Wilen 02 March 2007 20:21

Neither is "better".

HDF: 100% compatible, works also with programs that need low level disk access.

Directories: "compatible enough" if not using FAT, very flexible, can be accessed easily from host side, "unlimited" size etc..

adolescent 03 March 2007 00:59

What about Amiga hard drive support? Where would that rank?

Toni Wilen 03 March 2007 13:12

Quote:

Originally Posted by adolescent
What about Amiga hard drive support? Where would that rank?

Same as HDF. No difference.

StrategyGamer 03 March 2007 20:33

Which is better for programs and games which spool video or audio data from the HD with realtime playback?

In other words which is easier for the UAE virtual machine to deal with?

Or put another way: Which way burns less cpu cycles? A Hard Disk File or an NTFS dir?

andreas 11 June 2007 05:17

Quote:

Originally Posted by Kodoichi
Paul, in the Workbench 3.1 tutorial, why do you suggest creating a HDF with limited space? Creating folders in Windows, then assigning WinUAE to it is simple and doesn't limit space :confused

I hate to have 1000+ tiny files on my HDD, with some of them using illegal characters (in Windows terms), and have the thing fragmented as heck, too.

_ThEcRoW 13 July 2007 05:01

You always can use a real ffs/sfs partition on your hard disk for winuae.
It works very well :D.

hamster 05 August 2007 22:49

I find myself using a .hdf file labelled as "system" with my programs/games. I also attached a windows folder with the any needed tools for amiga/whdload etc reinstalls or for dragging files across windows to the .hdf.

Hmmm, I feel like creating another .hdf tonight.


All times are GMT +2. The time now is 22:21.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.04556 seconds with 11 queries