text:
Talk:Universal Disk Format

Revamp and update 2021
The OS support page really needs an update to reflect current state. It also needs to be reformatted to clearly state if an OS can *read* or *write* it. For example the (dated) Linux entry claims non plain VAT support, but can the kernel write it or only read it? Same for the other OSes. Also missing file system checker support shipped with the OS. Only OS I currently know has a good one is Windows7+ IIRC.

I haven't done the reformatting yet since I don't know the state of all the OSes and can't just test them out. Reinoud (talk) 16:24, 28 November 2021 (UTC)

Untitled
Link to Toshiba UDF2.5 Reader http://www.csd.toshiba.com/cgi-bin/tais/support/jsp/download.jsp?soid=1476333

WHY CAN I NOT LOGIN INTO THE ENGLISH WIKIPEDIA, EVEN I HAVE A USER IN THE GERMAN WIKIPEDIA?

This is me. http://de.wikipedia.org/wiki/Benutzer:Walter_H. — Preceding unsigned comment added by 194.48.32.17 (talk) 08:42, 13 December 2011 (UTC)

A new substitue for "flavour"
I've recently come to the conclusion that, perhaps, type is not the best word to substitute for flavour. I suggest the term "build" in their steads. I believe it conveys technicality, is accurate than both, and is an officially used term througout the industry for many different technologies. As updated versions of the standard are styled "revisions", there is also no confusion between the two.

GuelphGryphon98 (talk) 16:58, 5 August 2008 (UTC)

Types, not flavours
UDF is not ice cream, it doesn't come in "flavours", so don't use that word. It's unprofessional, and silly. It brings down the tone of the whole article, making it look amateurish and juvenile. This is a universal resource, and its reputation is in part based upon the carefully chosen verbiage of those who contribute articles, so try your best to make use of more technical words when discussing a technical subject, otherwise the article looks ridiculous and Wikipedia's reputation is tarnished.

GuelphGryphon98 (talk) 19:38, 14 July 2008 (UTC)

 * I believe *flavour* is a common word for variant or subtype in the CS jargon, most notably when referring to one or more "Unix flavour". For similar usage in a different academic field, see Flavour (particle physics). Eroen (talk) 00:49, 11 March 2012 (UTC)

Could someone add to the article what a 'build' means in this case. The more specific the better. I was confused by the word. Put a couple of lines in the relevant section.

85.97.171.201 (talk) 10:43, 11 February 2012 (UTC)

History
I personally don't like the way the history is written, as it's inaccurate and not in readable text. May I propose something along the lines of:

 * The UDF filesystem was standardized by the Optical Storage Technology Association to form a common file system for all optical media, be it read-only or having (limited) re-writing capabilities. This is still the main goal for ongoing UDF standardisation, although support for the more obscure WORM media is about to be limited, and support for non-optical media may be added.
 * When it was first standardised, the UDF filesystem was intended to replace ISO9660, allowing support for both read-only and writable media. Almost directly after the first version of UDF was released, it was adopted by the DVD Consortium as the official filesystem for DVD Video and DVD Audio. Nowadays, a UDF file system may be found on most authored optical discs in the market, and on almost all recordable DVD media that are used for video recording.
 * As intended, initially UDF was mainly found on optical media. Most operating systems needed special third-party software to support reading it. Nowadays, almost all operating systems natively support at least reading UDF file systems, and many support some form of writing as well. Because of this increased support, UDF is gaining popularity on non-optical media that mainly need to be exchangable, such as Iomega REV discs, large flash media, and even on hard disk drives.
 * As intended, initially UDF was mainly found on optical media. Most operating systems needed special third-party software to support reading it. Nowadays, almost all operating systems natively support at least reading UDF file systems, and many support some form of writing as well. Because of this increased support, UDF is gaining popularity on non-optical media that mainly need to be exchangable, such as Iomega REV discs, large flash media, and even on hard disk drives.
 * As intended, initially UDF was mainly found on optical media. Most operating systems needed special third-party software to support reading it. Nowadays, almost all operating systems natively support at least reading UDF file systems, and many support some form of writing as well. Because of this increased support, UDF is gaining popularity on non-optical media that mainly need to be exchangable, such as Iomega REV discs, large flash media, and even on hard disk drives.

I am intentionally dropping the information here about 2TB limit (which is incorrect by the way), the 32GB limit for FAT32 (untrue), the resource fork mention (not relevant to history), and the incomplete lists of supported media (inaccurate and not relevant to history).

Any information that goes missing because of this should be included (in text) elsewhere in the article.

I'd appreciate some feedback on this. Pieter-Bas 15:45, 29 May 2007 (UTC)

——————————————————

The history is incomplete and not quite correct. It is also important to remember that OSTA is not an accredited standards body, and as such, cannot standardize anything. They may be responsible for maintaining and upgrading an industry standard, but they do not standardize.

The development of the standard actually began with a file system developed by Optotech, a KPCB-funded startup company in Colorado Springs, in 1987. They were looking for a marketing angle to help them sell write-once-read-only (WORM) optical drives. They developed a file system, loosely based on some concepts from UNIX, that allowed the interchange of files between BSD UNIX (Sun), Macs, PCs and DEC VAXs running VMS. This was reasonably novel, because large volumes of data could be moved between machines transparently. (All of their software products mounted the file systems natively, allowing applications to access the optical media directly) Optotech at first sought to patent the format, but then realized this was a bad idea, and began to pursue standardization by working to form an ANSI technical committee known as X3B11.1. Members of this committee included representatives from Optotech, AT&T Bell Labs, DEC, IBM, Kodak, Toshiba, Phillips, and others. Sony and some others were pushing to use the CD-ROM standard, ISO 9660, on their rewritable optical media. This would have been a serious technical mistake, and the committee began work on a more general version of the Optotech file system - one that would work for WORM, premastered, and rewritable media - without the performance concerns and limitations of ISO 9660.

The assets of Optotech were purchased by Hewlett Packard in late 1989, because Optotech's funding dried up and HP was developing their own magneto-optical (rewritable) disk drives, and they saw value in what Optotech had done. Furthermore, they continued to champion the development of the standard. At this point, other companies joined the committee, including Microsoft and Sony.

The overall goal was to rapidly develop an ISO standard, which would be necessary for international agreement. The quickest way to do this was to perform the technical work in the ANSI committee, since most of the qualified personnel were in the United States. The formal ANSI approval process was very slow, however. The committee strategy was then to quickly move the technical description to ECMA, which had a fast track approval process which would permit it to be considered for an international standard. Once ECMA 167 was approved, the transition to ISO and the ISO 13346 standard was quick.

The group worked hard to ensure that data structures were present in the media which would allow for the needs of known operating systems and had sufficient extensibility that future requirements could be accommodated. Unicode was emerging, and generous allowances were made for diverse character sets. This left the standard needing further work to formalize the use of how file system data structures would be used in specific settings. This work could safely be done by a industry groups who would effectively act as registration authorities for these use profiles.

OSTA is apparently one such industry group who has chosen to champion the UDF moniker, and to make changes to the format within the confines of the standard. I haven't followed the work of OSTA after the ISO standard was approved. I was the software development manager at Optotech, moved to HP with the purchase. I was chair of the ANSI committee that developed the US version of the standard, and was a delegate to ECMA and ISO for the final standards approval process. If you have any questions, feel free to send me email. Ed Beshore (ebeshore at lpl.arizona.edu)

UDF partition identifier
What is the correct GPT or MBR identifier for UDF hard disk partitions? Chithanh 08:01, 17 April 2006 (UTC)

 * There is no correct GPT nor MBR identifier as UDF file system is expected to be on whole disk without any MBR/GPT table and without any disk partitioning. So there is no GPT or MBR identifier.
 * But if your question is What is the best GPT/MBR identifier id choice for UDF partition to achieve maximal compatibility with more operating systems?, then answer would be MBR identifier 0x07 and GPT GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. For detailed analysis, see following serverfault answer: https://serverfault.com/a/829172.
 * Pali UDF (talk) 09:10, 9 September 2017 (UTC)

Flavors
I have added the flavors because somehow this information needs to be made available to UDF users. I've tried to explain it in both a technical way (which internally happens) as well as how it applies to the user who wonders why his UDF 1.5 compliant OS can't read his UDF 1.5 compliant UDF disc (as in the example of the Sony Mavica CDs).

I have not found a better word in place of "flavor" (or flavour) but if you have one, please update the text accordingly. Another one that came to mind was "variant" - however, since it's always hard to talk about these flavors, the more unique and outstanding this term is, the better, I think. Ask yourself: If you ask someone which "flavor" of UDF is on the disc, it may be better understood as if you'd ask him which "kind" or "subformat" he uses.

My knowledge may be outdated. I've been actively participating in the specification of UDF 2.00 (and 2.01), but not in later versions.

I am also not sure about DVD+RW - do its sectors wear out as they do with CD-RW and DVD-RW?

One more thing: I actually do have UDF 1.5 compliant test images for the Original, VAT and Spared format (as well as for Strategy 4096, which is rather seldomly used), made years ago when working for Adaptec. They used to be openly available from Adaptec's ftp server until they vanished when no one cared for them any more, apparently. I could publish these on a separate server if someone could suggest a public place for them. They're about 13MB in size together.

-- Tempel 07:38, 7 March 2006 (UTC)

 * ftp://claunia.com/uploads/ (anonymous), you're welcome.
 * Upload them and let me a message so I move them to an appropiate folder.
 * Bandwidth isn't marvelous, but, it is a place.
 * Regards —Claunia 15:31, 7 March 2006 (UTC)

 * DVD-RW and DVD+RW have cyclability issues similar to CD-RW. Packets can be overwritten a limited number of times, after which they get tired/damaged as well.
 * I removed the comment about Windows 2000 not being able to read UDF 1.50 spared or VAT.
 * Media with sparing tables are detected as well. Windows 2000 requires the standard to be followed though. This means that the packet length must be set to 32 in the sparable partition descriptor. DVD media using UDF 1.50/Spared with a recorded packet length of 16 cannot be read by Windows 2000 without installing additional software.
 * Given that there is no officially accepted errata RFC for UDF allowig other values there, I consider this a reasonable requirement.
 * As for VAT, it is detected pretty well by Win2k. The main problem with getting Windows 2000 to detect UDF 1.50 + VAT formatted media, is drive support. Even on finalized media, many ROM drives have problems finding the last recorded sector properly. This, oddly enough, also highly depends on the quality of software for the recording drive. Typically drives have less problems with DVD+R media than with DVD-R.
 * Still, Windows 2000 supports UDF 1.50 with VAT and with Sparable Partitions, according to the UDF standard.
 * Pieter-Bas 08:00, 15 May 2006 (UTC)
 * As for VAT, it is detected pretty well by Win2k. The main problem with getting Windows 2000 to detect UDF 1.50 + VAT formatted media, is drive support. Even on finalized media, many ROM drives have problems finding the last recorded sector properly. This, oddly enough, also highly depends on the quality of software for the recording drive. Typically drives have less problems with DVD+R media than with DVD-R.
 * Still, Windows 2000 supports UDF 1.50 with VAT and with Sparable Partitions, according to the UDF standard.
 * Pieter-Bas 08:00, 15 May 2006 (UTC)
 * Pieter-Bas 08:00, 15 May 2006 (UTC)
 * Pieter-Bas 08:00, 15 May 2006 (UTC)

The Pieter-Bas from Philips? Nice to see you here! Thanks for clarifying some questions. I had made tests with my old CD media I made at Adaptec/Roxio, and that was not read by Windows 2000 SP4. Odd, but if you say you were able to read such disks on Win2K, then I won't argue. Tempel 22:58, 25 May 2006 (UTC)

 * Yep. The very same. Back then I spent a a week or two making sure my UDF 1.50 discs were actually read by Win2k SP4. Actually hooking up windbg and running in checked mode helps a lot there. If the media are refused, you can typically see why in the debug output. Still, problems always remain, especially when the drive can't reliably determine the disc properties. Pieter-Bas 15:37, 2 January 2007 (UTC)

limits
What is the maximum size for a file under UDF file system?--Ctac 07:52, 12 July 2005 (UTC)
 * I think it's 1 GiB - and I base that solely on how DVD video files are segmented. Don't trust me. Tokachu 00:09, 25 July 2005 (UTC)
 * Actually, it's 16 EiB. VOB files on DVD Video discs are broken up into 1 GiB chunks for backward compatibility with ISO 9660 and legacy operating systems. —Ghakko 15:30, 25 July 2005 (UTC)
 * The reason for 1 GiB chunks has nothing to do with backwards compatibility. In a file's allocation descriptors that describe the chunks a file is composed from, the length of a piece is 30 bits wide i.e. 1 GiB since the top two bits are used to hold flags telling its allocated, freed, free or if its specifying a continuation descriptor. Reinoud 22:11, 4 January 2007 (UTC)
 * To answer the question, the maximum size of a file is indeed 64 bits i.e. 16 EiB though only when sparse. Current UDF versions upto 2.60 allow only one writable physical partition descriptor thus limiting the size to 32 bit sector numbers i.e. with 2 KiB sectors this makes 32+11=43 bits giving 8 Tib. When multiple physical partiton descriptors are allowed an additional 16 bits are available giving 59 bits i.e. a half EiB spanning the whole disc. Reinoud 22:11, 4 January 2007 (UTC)

All allocation descriptors need to be in a single sector and depending on the amount of meta data there is only space left over for ~ 200 * 1 GB.
 * If you believe that UDF supports more than ~ 200 GB, please explain with pionters...

 * What makes you think that all extents need to be in a single block? In UDF, a block of allocation descriptiors may be ended with a pointer to a next extent of allocation descriptors. This next block will start with an AXD header (allocation extent descriptor). This pretty much allows files to endlessly grow on UDF, making the size of the volume (or 2^64 bytes, whichever is less) the limit for the allocated space of the file on UDF.

 * Given that sparse extents (extents that are not allocated) are supported, the file size may be much larger. The information length is recorded in 64-bits though, making that the practical limit. Though in theory a file can be larger if it has a file tail (2 ^ 64 bytes of sparse extents, plus the remaining volume size as allocated but unrecorded space in the file tail).

 * The practical limit is 16 EiB though.

 * Pieter-Bas 06:20, 10 October 2007 (UTC)

InCD
Which UDF version do you suggest?

I think, 2.01 for cdrw.

Windows XP Pro SP2, LG GSA-4136B

The article says right now:

Lately, however, it has also become popular with large and fully rewritable cross-platform media such as:

* Flash media above the Microsoft FAT32 (Windows XP) limit of 32 GB per disc

According to the article File Allocation Table, FAT32 has a limit of 2 TiB, so the above statement is wrong in my eyes.

--Abdull 20:52, 28 November 2005 (UTC)

 * Yes, but Microsoft has deliberately crippled the disk formatting tool in recent version of Windows. Basically, they want people to use NTFS, which is still not well supported by other operating systems e.g Linux, Mac OS X, and the BSD's. By limiting the size of FAT32 filesystems they provide a seemingly plausable reason to migrate. More subtle than simply dropping support outright. Imroy 07:00, 20 March 2006 (UTC)
 * The limit you mentioned only applies to formatting and installation, Windows 8 can still read or write 2 TiB FAT32 partitions. — Preceding unsigned comment added by 188.57.10.129 (talk) 09:10, 31 January 2013 (UTC)

what is Old and New Operating systems ?
Is discontrinued IBM OS/2 an example of OLD operating system? I bet it is. Is Windows (XP/2o03/forecoming Vista) example of New operating system ? I bet it is. But Windows cannot write to UDF without 3rd-party apps, while OS/2 can.

So splitting Operating systems to old and new is quite strange and confusing in this article.

 * Wait a minute, WHAT OS/2 can write to UDF without 3rd-party?
 * As far as I remember people in my local OS/2 user group must use 3rd-party to write UDF...
 * Can you provide proofs?
 * —Claunia 15:37, 7 March 2006 (UTC)

UDF Reader For Legacy OS
http://www.download.com/Adaptec-UDF-Reader-Driver/3000-2100_4-9497911.html

 * Doesn't work for Windows 95. Maybe it only supports a specific version of UDF i.e. those burned using Adaptec's packet writing DirectCD. --Voidvector (talk) 07:47, 24 September 2008 (UTC)

Write support needs flavor specification
The section "Native OS Support" lists supported UDF revisions along with broadly claiming write support in some cases, which is not always correct, because some of those File Systems only support Write for the plain flavor, but not for all UDF 1.5 or later flavors. Hence, the info there is incorrect giving the impression it supports writing to UDF 1.5 media such as CD-R when it, in fact, doesn't. An example are all OS X versions up to 10.4. They only write to plain random access media (old DVD-RAM, hard disks etc.) but not to -R or -RW media using the new flavors.

DVD+VR
Can somebody write this page? The DVD+VR one? There is not one thing on it and all the links to such a page go to an editing page.--Nytemunkey 06:45, 15 June 2006 (UTC)

 * Done. Please check the DVD+VR page. I added a talk page with information of which I know it's missing. Pieter-Bas 15:39, 2 January 2007 (UTC)

32 Gb limit on FAT32?
The article claims a 32Gb limit on FAT32 under Windows XP. The size limit for FAT32 is much larger than this. The only issue with Windows XP is that it will not format any device (or partition if appropriate) larger than 32Gb. However, larger than 32Gb devices otherwise work perfectly with XP.

Could it be referencing the 4GB single file size limitation of FAT32? 24.14.61.102 05:13, 9 March 2007 (UTC)

Windows XP doesn't allow formatting FAT volumes larger than 32GB, yet the limitation for the FAT FS itself is indeed much bigger. This should either be removed or clarified if it's still in. Pieter-Bas 15:05, 29 May 2007 (UTC)

Please update "write" capabilities in the table
Since hardly any one had paid attention to the "flavors", I have added a note that states that by default, OSs do not support the VAT and Spared flavors but only the "plain" flavor.

Yet, some OS seems to support the flavors, some even in writing. E.g, Windows Vista supposedly supports VAT and Spared flavors even in writing. Can someone please verify this by writing both to a CD-R and a CD-RW in packet writing mode and then update the table accordingly? Please do not blindly believe it unless you have tested it. If in doubt, ask me - I have a lot of practical knowledge of UDF and packet writing and can help.

Thank you -- Tempel 08:06, 12 October 2006 (UTC)

Does Linux 2.6.x really support the Spared flavor in writing?
I am doubtful that Linux 2.6 supports writing to CD-RW in Spared flavor, but that's what the article suggests in the list of OS support at the bottom. Can someone confirm that it really includes support for this? Meaning packet writing to CD-RW where you can delete files and add files at will? I had a search for such a feature in Linux and could not find it myself. Could you point me to a spec or even the source code? -- Tempel 08:11, 12 October 2006 (UTC)

 * There are two separate issues here:
 * The Linux UDF driver supports read-write on any writeable block device. These include hard disk partitions, flash and DVD+RW discs (which I regularly use for simple backups).
 * CD-RW discs are a special case; a separate driver is needed to do the background formatting and re-blocking to make the disc appear as a writeable block device.
 * I have to point out, though, that performance is horrible when writing large numbers of small files.
 * —Ghakko 13:05, 10 January 2007 (UTC)

Plain (Random Read/Write Access). This is the original format supported in all UDF revisions
This is wrong: the original format is read only partition as in UDF 1.0x. Rewritable partitions came only with UDF 1.50.

 * Nope. UDF 1.02 is actually also intended to write, hence the 'reading' and 'writing' hints in the specification. As for partition types: The older UDF specifications didn't repeat anything that was not restricted or refined from ECMA167-2. Also, additional partition types (VAT and Sparable partitions) were introduced in UDF 1.50 to enable random access writing on packet-written media that are otherwise not randonly overwritable, such as CD-R and CD-RW. Pieter-Bas 15:46, 2 January 2007 (UTC)

UDF 2.50 on Linux
Stock Linux 2.6 kernels do not support UDF 2.50 at all, see http://linux-udf.cvs.sourceforge.net/linux-udf/udf/linux-2.6/udf_sb.h?revision=1.8&view=markup#l_7

There is a patch for read-only support floating around, but it has not been accepted yet (http://sourceforge.net/tracker/index.php?func=detail&aid=1476807&group_id=295&atid=300295). —The preceding unsigned comment was added by 68.126.150.3 (talk) 02:29, 8 January 2007 (UTC).

Unicode?
How does UDF store file names? Does it use Unicode? Shouldn't the fact it does or not be mentioned in the article?-- Saoshyant talk / contribs (I don't like Wikipedophiles) 14:41, 17 January 2007 (UTC)

Yes. See Comparison_of_file_systems.

--Xerces8 12:44, 5 May 2007 (UTC)

Ubuntu?
Ubuntu belongs to Linux 2.6.x operating systems. Or does it have some own implentation? If not, it should be removed or other distributions should be added (wich doesn't make sense imho). Sevcsik 10:19, 21 April 2007 (UTC)

 * Ubuntu is Linux and as far as I know supports UDF like every other Linux distribution does.-- Ivo Emanuel Gonçalves talk / contribs (please join WP:PT or WP:SPOKEN) 22:20, 29 April 2007 (UTC)

Vista's "Live File System"
I am talking about the default formating choice for discs under Windows Vista. Apparently it is some sort of UDF. But what exactly is it? Microsoft describes it as "packet writing" UDF. Is that Microsoft speak for "VAT" or "Spared"? Or is it something else? I have heard that it is not well supported, which fits those two flavors. If it is one of those two I congratulate Microsoft for actually using a standard, and in the way it was intended, but regret the limited compatibility of the resulting discs due to the limited implementation of those flavor in other OSes. Tacvek 03:30, 8 May 2007 (UTC)

 * Packet writing UDF is either VAT or Spared. The only way to write to DVD-RW, DVD+RW, DVD-R or DVD+R media using UDF (in such a way the media are re-writable) is using Packet Writing technology on physical level, and using UDF+VAT (DVD+R/DVD-R), UDF+Sparing (DVD-RW/DVD+RW), or plain UDF (DVD-RAM). So, I think MS is actually following the standard. I didn't check this though. As for limited support on other OSs: The standard is open, and I don't see any reason why the open source community can't come up with a working UDF implementation for packet-written media. Pieter-Bas 15:52, 29 May 2007 (UTC)

Using the term "flavor" vs. "version"
I am the one who introduced the term "flavor" a while ago here in order to add awareness of the VAT and Spared types of UDF.

No one seemed to have a problem with this, and I noticed that others adopted this term as well in recent years.

Now someone anonymously changed the article by replacing "flavor" with "version", which, IMO, is a bad choice as it adds confusion (imagine saying: a hard disk is usually written in the "plain version" of UDF). Therefore, I changed it back to "flavor".

Is there a consensus that we keep using "flavor" here?

Does anyone inside the OSTA UDF group know what term is used there now? Pieter-Bas, what you do think?

Tempel 10:27, 26 September 2007 (UTC)

 * I have given this some thought. I think flavor is awkward, but version is definitely not the right word. We use "UDF version" for the the version number of the specification, not for the specific type of volume that is being recorded. By lack of a better word, flavor is good to use. Pieter-Bas 06:24, 10 October 2007 (UTC)

 * If Wikipedia wishes to be a universal and professional resource, its contributors ought to stop doing certain things, particularly the use and creation of what amount to slang terms ad hoc. The purpose of Wikipedia, as I see it, is to ultimately acheive the same academic quality and consistency of such encyclopaedias as Brittanica, and in this endeavour the proper choice of language is essential, the proper choice of professional and academic language specifically. When discussing a technical subject, more technical or neutral words are called for. As Winston Churchill said, to improve is to change, to be perfect is to change often. Confusion wrought by change will in time turn to clarity, as long as there is consistency, this should not something to fear. In substitue of "flavour", I would suggest "variety", "type", or "build". Of these I prefer "build", as it is easily understood, conveys technicality, and is already in official use in many technical areas, and isn't a slang term.

GuelphGryphon98 (talk) 16:49, 5 August 2008 (UTC)

 * "Flavor" is actually a relatively common term in some software circles. In BSD for example, the different distributions/types/what-have-you are generally referred to as flavors. By extension, some Linux distributions and other forked free-software projects sometimes use the term too. It's not necessarily the right term for this article, but its not exactly a slang term, and it's not without some precedent. Patch86 (talk) 22:36, 5 March 2009 (UTC)

Copyright violation at diskinternals.com?
Someone added a link on the article page that went like this:

 * http://www.diskinternals.com/glossary/udf.html l Good UDF writeup

When I checked that article out, I found that it was not a writeup, but a direct copy of this wikipedia article!

I sent them a mail through their contact web form and asked them to either include a reference to the wikipedia article in order to honor its origin or remove the text.

I've also removed the above link from the article here for the lack of additional information in the ref'd page.

Tempel 20:30, 27 October 2007 (UTC)

 * This issue has not yet been resolved. I sent a reminder via the web site's contact form. Pieter-Bas (talk) 22:08, 13 December 2007 (UTC)

 * DiskInternals responded with "Can we resolve this problem by sending to you a key for one of our products for free?". I asked them again to either comply with the conditions for re-using content that was published under the GFDL, or remove the content and replace it by an original work. Awaiting a reply. (More of their glossary violates the GFDL by the way. Is there some official wikipedia policie for dealing with this?) Pieter-Bas (talk) 13:32, 16 December 2007 (UTC)

 * Not really, the best we have is Mirrors and forks. If they continue to ignore your request, you may want to follow the suggestion for a DMCA take down notice since it appears you have contributed to this article so they may be violationg your copyright Nil Einne (talk) 10:32, 18 January 2008 (UTC)

 * It looks like their stealing someone else's work now Nil Einne (talk) 10:15, 20 January 2008 (UTC)

Metadata partition not a flavor
The metadata partition is a mandatory extension of UDF 2.50, and thus does not constitute what the "flavors" are meant for. The term "flavor" was introduced by me to explain the different support levels of a single UDF version, in order to communicate how a UDF 1.50 disc may use one flavor or the other. This was necessary because lots of software, while claiming to support UDF 1.50, did not support all flavors.

A filesystem supporting UDF 2.50, however, clearly has to support metadata partitions, and hence we do not need a "flavor" for distinction here.

That's why I've undone Reinoud's changes now.

Tempel (talk) 18:00, 6 February 2008 (UTC)

I disagree; the fact that it was introduced in version 2.50 doesn't mean that it isn't a flavor! You can still create valid 2.01 discs in plain format on a CD-R or CD-RW without needing VAT or sparable partitions. OK, it wouldn't make much sense to choose to format it in even 2.50.

I think its confusing to mention specification versions even. F.E. linux claims to be able to read upto 2.01 but give it a CD-R with a 1.50 or 2.01 VAT partition and it will choke. Similar arguments can also be given for other implementations.

I think it would be better if we create one table with horizontally media (like CD-R, CD-RW, CD-RW, CD-MRW, DVD*R, DVD-RW etc. etc.) and vertically each implementation/OS and on the crossings the specifics they support: like CD-R crossed with NetBSD it would be "reading: plain, VAT" and "writing: -". The tables can also be split and the names be shortened to single letters like:

Idea?

--Reinoud (talk) 17:47, 13 March 2008 (UTC)

Windows VAT Support
The chart says that none of the versions of Windows supports VAT. I know that this is not true. Windows does read UDF with VAT. —Preceding unsigned comment added by Ososnilknarf (talk • contribs)
 * Those cells are empty. It only does not support it if it clearly says "NO". You can fill them in if you want. I made the chart from an ad hoc style list, which didn't include all the information. --Voidvector (talk) 01:12, 3 December 2008 (UTC)

Chart Format
The chart is still not what i'd like to see. Its still not clear as to which implementations can write what media types and in what build though a lot better than it used to be. --Reinoud (talk) 19:38, 16 December 2008 (UTC)

 * I think there is significant room for improvement, but it is hard for an average contributor to get access to all those OSes. It takes hours to download/install those OS, then you need to learn how to mount/unmount/create CD/DVDs. Now, if you work somewhere where you have all the OS images readily available, and know how to test for this, be my guest, I like to know the compatibility of various systems too. --Voidvector (talk) 23:38, 16 December 2008 (UTC)

 * A start would be to design the chart so that all UDF versions/`builds' can be described as '??'/'RO'/'RW'. The problem now occuring is that for VAT its possible to have 1.50 VAT and 2.0x VAT; they are different. Maybe version coloms that are splitted into coloms themselves for the various builds? The question we should keep in mind however is the purpose of the table and if it shouldn't be splitted up into two tables. What would a reader want to derive from the table or is it an extensive description of what OS supports As simple as upto what version can i format my disc before OS A can't read/write it anymore (since i haven't seen implmentations that are say only from 2.01 only). So maybe for OS A it would be sufficient to say UDF 2.01 for VAT reading but UDF 1.50 for VAT writing. Where as for OS B it could be that no sparables are to be read/written but plain is upto 2.01. (Side note: 'Meta' should be a build too IMHO). Maybe the user wants to know what media (CD/DVD/BD/Flash/...) an OS supports and what versions and builds. A seperate Read and Write table can also be an option. Too many variants... --Reinoud (talk) 10:16, 17 December 2008 (UTC)

Windows XP Native Write Support
Windows XP does not natively support writing UDF on DVD-RAM discs. It does support writing FAT32 on DVD-RAM disks. I just verified that on Windows XP SP3 on Leneovo ThinkPad T60p which have a DVD-RAM drive. I'm changing the table to reflect that.--76.31.205.97 (talk) 17:36, 21 March 2009 (UTC)

 * Does it support native UDF writing on other types of disks?. — trlkly 04:43, 18 October 2009 (UTC)

The OS chart
This table is based almost entirely on original research. It's also questionable how to select which operating systems are put on the list, considering that there are many hundreds of operating systems and versions that may be of interest to someone. The formatting of the chart is also based on the concept of UDF "builds", which as far as I can tell is also an original idea of the Wiki editors. To the layman, the question is not what particular types of UDF partitions are supported, but whether the specification Revision is fully (correctly) supported or not, and if not then a source should be provided that explains the particular details for that OS. I don't think a chart like this is really necessary once the data is limited to verifiable sources. If editors insist on maintaining a chart, then I would suggest that you at least move it to its own page where it is less of an eyesore and does not impede on the quality of this article. For the time being I am going to remove the chart and see how that is received. If an editor wishes to retrieve the code for use on another page, it will be accessible from the article revision history prior to this timestamp. Ham Pastrami (talk) 01:03, 20 March 2010 (UTC)

Where did the OS support table gone??? The most informative thing about UDF article is that table!!! You seriously hindered the quality of this article. Particular OS details could be explaind and they are explaind partially. They need to be displayed even further but I do not see as apropriate action for table to be simply removed. No need to move it to another page, since it is very informative and ON topic. If you wanted to make OS support it on new page, you could do it instead of just deleting it. Reviving it for visitors sake (table was here for years and i just came to se what is NEW with OS support for USF..!) until your comments are worked out in some positive way other then simply deliting main part of the article.Minikola (talk) 08:06, 22 March 2010 (UTC)
 * Do you have sources for the chart you are putting in the article? Do you have sources for information other than self-references like the OSTA spec or the Philips page where they sell the verifier software? This article is not a place to quote highlights and trivia that you personally find interesting. It's supposed to be an encyclopedia article, sourced to verifiable secondary coverage. Ham Pastrami (talk) 10:11, 22 March 2010 (UTC)

Making article better takes time and effort and thank you for your contribution and effort. But destroying more then half of useful and ,to my knoledge by example, true data, is not a way to make wikipedia better. It needs to be referenced better so it can wait to be done a little bit more. Dont be inpatient and do not destroy others work but improve on top of it.Minikola (talk) 14:36, 22 March 2010 (UTC)
 * Unfortunately I do not agree that what you are adding to the article is useful, and in some cases your choice of language is not even neutral. The fact that you can only attest "to your knowledge" rather than providing actual sources is admission that the content you have added/re-added is OR. Correct? As for time, this article has been in this unreferenced, low-quality state for a period of years and no indication of any reliable sources have surfaced. Time is up. Simply because you personally like UDF or have some kind of personal interest in it is not justification for failing to provide verifiable evidence of your claims when challenged, nor is it justification for adding trivia. You even reverted changes that cleaned up the language in the article, and replaced it with misspelled words. You can barely even write and yet you profess to be improving the quality of the article? Please address the concerns that I raised instead of performing unilateral reverts and changes that lower the quality of the article. Ham Pastrami (talk) 03:58, 23 March 2010 (UTC)

In multiple ocation, you Pastrami, choose not to tell the truth. I did not just reverted content on page that was there for YEARS and contributed from hunderds of users (that you are simply deleting with false accusations on my behlaf) but you actually trying to destroy article itself, like you have something against UDF as it is.

I was happy to do some research today on a matter and I also build on top of Your changes, not against them! So I was mostly NOT adding Anything to the article myself but simply trying to save from web-vandalism you are doing right now. I told it takes Time to work out sources and things you mention and you seems doing inapropriate thing destroying article, again. I do NOT choose any language changes since I mostly add nothing new. I take no sides on UDF and not "being neutral" is your _false and errornous rethorics_. Stop destroying this article untill it is made better OVER TIME! Simply because you are calling me bad words does not make you any more better person, Pastrami. I builded only on TOP of your changes! And saving text from other people. Also YOUR choice of words is obviously ANTI-UDF and I have nothing more to say to you but to go and play elsewhere with your spare time and stop destroying informative articles on Wikipedia. (That is multi-refernced everywhere on internet, right now). Also if you have some problems with information that UDF is used on rewritible optical disks then it is your personal problem and not by the article itself. To say again, you pointed to the issue of need for referencing but you are doing that in mostly arrogant, errornous and not productive way. Please being like that, Pastrami Minikola (talk) 09:33, 23 March 2010 (UTC) Pastrami, it is NOT possible that All of the article is not referenced. You again deleted whole article that also Includes Your new changes. Please stop vandalizing article and do something on referencing part if you can. I can do some effort on that, as you can see, but deleting whole article (without stating: what exactly was there for years and you think is unreferenced is not productive). For some reason you don`t want people to know they can use UDF on their OS`es. I respect that, but this is Wikipedia, not your private web page.Minikola (talk) 10:11, 23 March 2010 (UTC)

Mr. Pastrami, please add more referenced data and please: point out what exactly is unreferenced and in what sections in the article, like you did with pointing in need for table to be referenced. Table is in progress.Minikola (talk) 10:37, 23 March 2010 (UTC)

I have to agree that the OS list features list is at least ambiguous and incomplete. As the author of the NetBSD implementation i can stand for the info accredited to NetBSD.--Reinoud (talk) 10:29, 3 September 2010 (UTC)

Using userland programs to master a disc is not what i consider OS support. --Reinoud (talk) 12:10, 3 September 2010 (UTC)

I must agree with Ham Pastrami and Reinoud. Wikipedia should also be submitted to at least basic academic standards of referencing to original material and not present original research (and partisan material as suggested by the two authors). It is inappropriate to start religious type of legalism and stating things like "to my knoledge by example, true data" should rather be based on supplying some references than more assumptions. I would also like to see OS's listed and the versions of UDF that are compatible with it. Where is the Linux 3.x Kernel data? UDF supporters and developers should publish some material that can be used as references in this article. 91.67.112.27 (talk) —Preceding undated comment added 08:04, 12 June 2012 (UTC)

The compatibility table is present and incomplete in the version I am reading today. I checked this page to find out the status on Linux 3.x kernel and found this raging controversy.

OS support of UDF to me implies system libraries available to user applications and kernel support of drive hardware so that user applications can author a disk, not 'OS support' for 'authoring a disk'. 'Authoring' in optical media can be anything from a single-session unalterable ROM data file repository to a multisession updatable ROM or RW to a specialized and rigidly specified multimedia package that functions autonomously in a stand-alone player. Even Windows and Mac does not support 'authoring a disk', unless one considers dumping data files to a ROM or RW to be 'authoring' (I do not).

The suggestion to split the 'supported' table and add much detail on the exact pieces of each specification that is implemented is interesting but impractical, and as far as the removal of the table or the article is concerned... is it really an improvement to 'upgrade' Wikipedia standards to those of for-profit encyclopedic sources that are demonstrably less complete and accurate in many cases?

Please keep in mind that for any OS that is GPL licensed, the people doing development share their work for free. As such, they also find up to date documentation to be a financially inuspportable burden in many cases, particularly for the implementation details of licensed specifications that they may not even legally own a copy of due to nondisclosure agreements that conflict with GPL and outrageous licensing fees that are designed to discourage free sharing of the technology. Much GPL-based work is 'legal' only in countries where software patents do not apply and the rest is underground if patent rights might be involved. This is well known fact of life in GPL. No one is going to add extra work to document philanthropic software that is 'illegal' in your country even if it is running on most of the web servers and PCs regardless of country.

Also please remember demands from Wikipedia on developers for free documentation and features will get the same response as all other user demands, ranging from polite disdain to open contempt for the sheer arrogance of such demands. Requests will only be honored if the software author deems them beneficial to his/her goals. Stubbornness from Wikipedia will doom it to irrelevance on GPL topics. In many cases the only available GPL software documentation will be original research from people who actually develop or try out the software and are kind enough to share their experience, until the development work itself is mature enough to justify diverting resources into publishing authoritative charts and tables. Saying 'time is up' is not a solution to anything where resources do not exist to satisfy arbitrary demands. In the case of free software, the only reliable documentation available may be in the form of source code and bug reports that no one except a developer even wants to read let alone link to. Do we want to inflict that on casual users of Wiki?

None of these unfortunate truths justify deleting charts or articles in order to comply with an inflexible policy. Reality is messy. At least when I come here to read about UDF I want a table even if the information is incomplete, unreferenced, original research, confusing to interpret, or even potentially wrong in some aspects, because it is better than nothing and already better than I could develop on my own after weeks of googling. I have to install and try the software to verify its usability for my application no matter who wrote it. What I need is a basis for comparison so that I can shorten the list of candidates to a manageable subset. If the table shows Linux 2.6 kernel is nearly complete I can reasonably assume that all Ubuntu and most Debian derivatives now have full support at least through 'userland' applications even if the OS table is incomplete and potentially misleading. Please at least give me the benefit of not having to do the original research myself!

Thanks for your indulgence. 68.183.238.154 (talk) 10:51, 21 August 2012 (UTC)

Just wanted to point out that the above unwarranted attack on GPL software is both wrong and off-topic for this article. GPL software is not affected by software patents in a different way than software licensed in other ways (except it gives you a bit more safety in that it gives you access to softwrae patents by the author). 109.193.229.175 (talk) 15:44, 27 November 2018 (UTC)

Character set?
The infobox says filenames can contain any Unicode character, while the "Character set" paragraph seems to claim something completely different (ASCII and variants of it). Can someone please clarify?

--Xerces8 (talk) 10:18, 9 December 2013 (UTC)

 * The only allowed Character Set is OSTA CS0 which allows storing any 16bit Unicode code point excluding U+FEFF and U+FFFE. See UDF specification, section 2.1.1.
 * Pali UDF (talk) 09:24, 9 September 2017 (UTC)

DosBox?
What's DosBox doing in the Table of operating systems? DosBox is more of an emulator than an operating system insofar as you can't boot it on bare hardware... 91.125.20.162 (talk) 18:07, 31 August 2014 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 3 one external links on Universal Disk Format. Please take a moment to review my edit. You may add after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add to keep me off the page altogether, but should be used as a last resort. I made the following changes:
 * Attempted to fix sourcing for http://support.apple.com/kb/TA26938?viewlocale=en_US
 * Attempted to fix sourcing for http://www.apple.com/downloads/macosx/apple/macosx_updates/macosx10411comboupdateintel.html
 * Attempted to fix sourcing for http://www.apple.com/downloads/macosx/apple/macosx_updates/macosx10411comboupdateppc.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 13:57, 31 March 2016 (UTC)

Use
A section discussing use would be appropriate. What are current use cases? Has the spared build any merit for a hdd? For flash storage? Regards, ... PeterEasthope (talk) 15:16, 27 November 2018 (UTC)

Sources claim Windows 7/8/9 does read/write for UDF 2.60
The OS support table seems wrong - the listed sources claim windows 7 and later support UDF 2.60 for writing in any variant. — Preceding unsigned comment added by 109.193.229.175 (talk) 15:39, 27 November 2018 (UTC)

Typing mistake
In the description on the right sight, at the date it says december 9999 - shouldn't it be 1999? 212.187.41.231 (talk) 21:09, 12 April 2022 (UTC)

 * Per https://www.ecma-international.org/wp-content/uploads/ECMA-167_3rd_edition_june_1997.pdf the date range of a file saved to a UDF device appears to be:

 * 24:00:00.000, 1 January 1 (UTC) – 23:59:59.999, 31 December 9999 (UTC)

 * I fixed the date. Please check for errors. Please double check for errors. In particular, can there be a non-UTC time zone? should year one be 1 or 0001? Am I right in thinking that there is no "0th hour"?2600:1700:D0A0:21B0:E447:37C4:18C6:8FDA (talk) 01:41, 22 July 2022 (UTC)

title: Talk:Universal Disk Format