Developer Forum

There seems to be a bug in UDF.IFS 2.1.4:
Cannot copy files w. extended attributes > 32k.
("Cannot access target file" copied file has 0 byte length)
Tested w. ACP2 and DVD+RW.

----------------------------------------------
Manfred Aigner


On Tue, 13 Jul 2004 21:55:49 UTC, "Manfred Aigner "



Yes, I get the same results with UDF.IFS 2.1.4 on an MCP2 system with
DVD+RW. I asked about it on c.o.o.setup.storage, and the person who
replied said he thought it was a bug that was present since the first
UDF.IFS

For removing *all* EA's (from images, mp3 and the like) I use 'tar' to
make an archive. After verifying that the tar archive is readable, I
delete original files and then write back the tar archive. Using FC/2 as
frontend eases the task.

Klaus Staedtler

Hi




That sounds like it was me.

The very first time that I managed to get udf working with a cdrw -
about 2 years ago - I discovered the EA problem as some bmp files that
had been opened and saved using PMView2000 were reported as "could not
be copied."

Interestingly while those files could not be seen from the WPS they had
in fact been copied - using dir from the command line revealed their
existence and they could also be opened by applications such as PMView.

I also find that this problem seems to apply to almost any type of file
but mainly with image and movie files. A classic example of this which
sticks in memeory was a file, n:\temp\readme.txt, which could not be
copied because "the filename is too long" - the EAs were about 5 times
the size of the file and once those EAs were removed the file copied fine.

This behaviour seems to have changed slightly as files reported as "not
copied" do not show up on the cdrw/dvdrw using the dir command now.

In the absence of a fix: Anyone got a script that can work through a
drive and remove oversize EAs?

Regards

Pete

What's wrong with something like this:
for %x in (*) do eautil %x NUL /S

Nothing, as always there are several ways. I'm used to the tar/FC2 way
cause it allows me e.g to select files within a directory etc.

Klaus Staedtler

The UDF developers have noted this bug. When other, more pressing issues,
are out of the way, they will
look at fixing it.
-Scott

Klaus Staedtler schrieb:


I use NOEA.EXE from the lxLite package, this is pretty straightforward.

Herwig

Thanks Scott

Great!
That's really very good news to learn about further improvements of the
UDF.ifs :-)

Wolfi

On Thu, 15 Jul 2004 14:06:31 UTC, "Scott"



My expectations are so low, that this comment has brightened my whole
day :)

--
Regards,
Al S. 

This OS/2 system ("Tori", W4 FP17) uptime is 5 days 21:24 hours

In <YdXcPjhdfZKu-pn2-ZUoUnOhFiFuS@tori>, on 07/17/04
at 02:27 AM, "Al Savage" < XXXX@XXXXX.COM > said:


Actually, the latest UDF is quite usable. Jerry Rash, who is basically
the SCOUG multimedia master and master hardware shuffler, gave us a review
of the current UDF capabilities this Saturday morning. With the exception
of DVD-RAM, it handles all the usual media types with good performance.
Driver performance is orders of magnitude better that the earlier UDF
versions. According to Jerry, the major remaining issue is media change
processing. There are still cases where a reboot is required before a
media type change will be correctly recognized.

Regards,

Steven

--
----------------------------------------------------------------------
"Steven Levine" < XXXX@XXXXX.COM > MR2/ICE 2.47 #10183 Warp4/FP15/14.093c_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------------------------------------------------

There also still is this long time "files with EA >32kB are not copied"
problem pending, recently reported in several posts.

Wolfi

Why does he think that DVD-RAM speed is not as good? While the UDF
driver lacks caching and hence appears a bit slow when compared to
Linux, the actual transfer of the files is not too bad (although I
forgot where I saved the numbers of same measurements I did). [Well, I
still don't have any DVD-+RW to compare to, they are very hard to get
here, if you don't want to pay 100% more for p&p, and I would want to
rely on them for my backups anyway...]
--
Greetings, Please reply in newsgroup, I rarely
Peter. read emails to XXXX@XXXXX.COM ...

> In the absence of a fix: Anyone got a script that can work through a

I got the same problem because my digicam images got a larger
PMView preview in EAs. Because I had a hughe amount of files
in many directory trees, I developed a small REXX script which
recursively removes all EAs from the files. An optional file
mask is possible. (EAUTIL does not work recursively)

In case you created light table folders for the images, the
script can also remove EAs from directories.

It's uploaded to Hobbes. Look for "del_ea_11.zip".

I hope we soon get a fix for the UDF issue.

Heiko