cisz said:
I was wondering if there's a size limit for copying files to a udf (incd)
formatted rwcd?
I've been able to copy small files with no problem but the large files hang
and I'm unable to end the program (windows explorer) using "end task" (task
manager). I end up having to reset and reboot.
I wondered if since the disk is being used like a floppy that it can't copy
files larger than 1.44M.
http://en.wikipedia.org/wiki/Universal_Disk_Format
UDF and CDFS run as installable file systems (IFS). See:
http://en.wikipedia.org/wiki/Installable_file_system
Since UDF uses packet writing/reading, a file can be rather long. See:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
According to that article, a file can be 16EiB in size (16 exbibytes;
see
http://en.wikipedia.org/wiki/Exbibyte). That would take 2^20 of 1
TiB hard disks to hold. In other words, the limitation based on the UDF
spec is it would take about a million million 1 TB hard disks to hold a
file that big. So far, there isn't as mass or removable storage that
comes close to that size. Of course, that also means that you can
create a file on a UDF device that easily exceeds the maximum size
allowed for files when you copy it to a different file system.
As I've read (but don't remember for what versions), Nero will limit you
to 2GB whereas ImgBurn uses level 3 so you can have 4GB files (but that
discussion was for ISO-9660 for CDFS). So how big the file can be will
vary depending on whose burning software you use.
It also depends on where UDF is implemented. For optical media, the
logical block size is usually 2KB (as noted by the article at
http://homepage.mac.com/wenguangwang/myhome/udf.html). If used on a
hard disk, it takes the sector size from the underlying file system or
expected sector size (so it is likely 512 bytes for a sector). There
can be 2^30 extants (logical blocks) so you get 2^11 * 2^30 for 2^41
bytes (yet I've read elsewhere that 2^40 bytes is the max) for optical
media.
So max file size depends on what type of media on which UDF is used, the
support provided by UDFS in the OS, and what burning software you use.
Microsoft probably doesn't specify a max file size because it depends on
the version of udfs.sys (i.e., for which version of Windows) and on what
type of media (e.g., hard disk versus optical) it is used; see
http://technet.microsoft.com/en-us/library/bb457112.aspx#EDAA. It does
mention that 64-bit file sizes are possible. Since each bit addresses a
logical block, how big for the file depends on how big is the logical
block and that differs based on the media (hard disk versus optical).
2^64 times 2^11 (for 2048KB sectors on optical media) means 2^75 bytes
but, I believe, that exceeds the ISO-13346 spec for UDF of 2^60 extants
noted at
http://www.osta.org/specs/ (for version 1.2 so later versions
might've upped that count). Plus you'll hit some physical limitation
long before then, like the size of the storage medium itself.
The file can be huge and can, by spec, exceed the size of the storage
medium that you use but other limitations may come into play that reduce
that size. For example, how are you going to do 64-bit addressing in a
32-bit operating system? Normally 32-bit controllers don't do 64-bit
addressing so software might come into play to emulate 64-bit addressing
but that would incur a performance penalty, plus the 32-bit addressing
probably gets you past the physical limit of the storage medium. 2^32
sectors times 2^9 bytes/sector (for optical media) is 2^41, and that's 4
tebibytes (terabytes in common parlance) for a file size.
As for Nero's InCD (from Nero), Roxio's DirectCD, or Sonic's DLA, they
have always and still remain flaky. I gave up long ago using those
installable file systems. If you use them, expect hangs. You're better
of simply deciding when to copy the files off your hard disk and store
them onto your [re]writable optical media using burning software. IFS
under UNIX seems to work rather reliably but I haven't yet seen a
reliable IFS to use under Windows (other than those provided by
Microsoft). You're just another user that thought it was a cool feature
only to find out later that it is just too unreliable to continue using.
