GNOME Bugzilla – Bug 469221
extract a package on an NTFS partition doesn't work
Last modified: 2007-08-23 20:07:05 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/127641 "... I've got an USB disk with NTFS partition. This NTFS partition is mounted RW with ntfs-3g. When i tried to extract an .ISO stored on this USB disk on this USB disk, i've encountered an ERROR. The details of the error is empty. When i tried to extract this same .ISO stored on this USB disk on a EXT3 partition, all is OK ... I don't know if this helps, but even .tar.gz does not extract in ntfs-3g partitions (using the extract here nautilus shortcut) the error is this: tar: filename: Cannot utime: Not implemented function ... It gives those errors, but it works. I think that file-roller extracts files in a tmp directory and then copies them to the current folder (not a good idea in my opinion), then it sees the exit vaule of tar (which is not 0) and since it finds an error, it thinks that something goes wrong and does not copy the extracted files in the current directory. Again, using the extract feature from the file roller window (not from nautilus) works, though it visualizes the same errors."
file-roller now ignores non-fatal errors (exit values smaller than 2) from the tar command, however I'm not sure if this change resolves the problem, because I've no ntfs-3g partition available in order to make a test. If the original reporter can download and compile the current svn trunk version, he could try and see if the problem is gone now.
Ntfs-3g can be tested without any NTFS partition. Only a Linux, FreeBSD, NETBSD, or OS X is needed: http://ntfs-3g.org/quality.html#howtotest I hope you find this useful for your testing. Btw, there is no known issue with ntfs-3g using tar. Utime(2) is implemented. The typical problems are if the user doesn't have the permission to do some file operations according to the mount options.
Thanks Szabolcs for the hint. Actually the bug was unrelated to the partition type, it was related to the extraction of iso images, it's now fixed in svn trunk.