Shell Tar giving (null) at the end

Hello, I am trying to tar a big folder and I was having a problem with it, at first it ended with this:

Code:
# tar -czPf /media/da0p1/crypt.tar.gz /mnt/text/
tar: Couldn't list extended attributes: Fichero o directorio inexistente
tar: (null)

So I added this option --no-xattrs:

Code:
# tar --no-xattrs -czPf /media/da0p1/crypt.tar.gz /mnt/text/
tar: (null)

It still ends with "tar: (null)" so, it ended correctly or with error? What that "tar: (null)" means?
 
It not ended correctly, it ends wrong. I can see the file should has like 400GB and it has only 1.3GB, so my question is how I can fix it?
 
Can you run tar with the "v" option? And then see on which file it gets the problem? It seems to me that the file system that tar is reading from is somehow damaged, with the extended attributes on at least one file unreadable (that's why you get the "no such file or directory" ENOENT message).

The "tar: (null)" message at the end means that tar is writing to print an error message, but for some reason it doesn't have one, so the string printing code prints "(null)". That is clearly a bug in tar. But you need to find out what exposes this bug. Again, run tar with the "v" option, and see what the last file that tar processed is. Examine that file, and look for errors.

By the way, the "P" option you are using is pretty unusual, and can be dangerous if used carelessly. Do you know what you're doing, or did you copy if from somewhere without understanding the possible implications?
 
If he hit "disk full" on the output file, or a maximum file size, he would get ENOSPC or EIO or some error like that. He clearly has input errors too. The "(null)" error is a little annoying.
 
I am running -v option now, and the file it's dropping over a external HD with NTFS
Hmm, NTFS plus external disk, on FreeBSD. That sounds like it could be unreliable. Maybe the "(null)" error message is caused by some bizarre error condition on the output tar file on NTFS, which tar mishandled and doesn't report? Maybe you should also watch dmesg and /var/log/messages while the tar is running.
 
This ended with -v option:

Code:
a media/da1s1/14/Access/Access
tar: /media/da1s1/14/paf: Couldn't visit directory: Unknown error: -1
tar: Error exit delayed from previous errors.
 
At this point, I would try running tar without actually creating an output file ( /dev/null instead of /media/da0p1/crypt.tar.gz ), to see if the problem is
with the media that the source files are on.
 
First, I like ljboiler's suggestion: separate the operation into two parts, test them separately, see which half fails.

Second:
This ended with -v option:

Code:
a media/da1s1/14/Access/Access
tar: /media/da1s1/14/paf: Couldn't visit directory: Unknown error: -1
tar: Error exit delayed from previous errors.
So the problem is when reading media/da1s1/14/paf. We have no idea what's broken with that file, only that tar reports a non-specific error code; -1 is probably the return from some operation like open() or read(). That's kind of sloppy programming on the part of tar, but good enough. Suggestion: Manually cd into those directory, and try reading the offending file or files, for example with "cat paf > /dev/null" or "dd if=paf of=/dev/null" or something like that. Also do "ls -l", and perhaps even look for special file flags and extended attributes. Generally, explore the land there and make sure everything is readable. My hunch is: You will find that something there is not readable, perhaps because you get an IO or file system error when you try to read it.
 
You know you have right, there is a problem with that foler. It looks empty but I can not delete it.

Code:
: /media/da1s1/14 # rm -rfv paf
rm: paf: Directorio no vacio
# rm -rf paf
rm: paf: Directory not empty
:/paf # ls -la
total 0

how I can delete it?
 
I'd start by checking the consistency of that filesystem. I think you mentioned NTFS? So it's time for chkdsk I guess, I'm not familiar with any tools on FreeBSD which can check an NTFS filesystem.
 
I'd start by checking the consistency of that filesystem. I think you mentioned NTFS? So it's time for chkdsk I guess, I'm not familiar with any tools on FreeBSD which can check an NTFS filesystem.

I coud not find this chkdsk but I did find ntfsfix so:

Code:
# ntfsfix -b -d /dev/da1s1
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
Going to un-mark the bad clusters ($BadClus)... No bad clusters...OK
NTFS partition /dev/da1s1 was processed successfully.

But I can not delete that folder...
 
I just removed the disk and mounted in another computer with Debian to delete those folders under conflict. Now I am running again on FreeBSD tar with -v option, I will let you know if this time ends normally
 
As you said: Most likely, this particular file system is damaged. Having a directory that can not be deleted because it is not empty, but that contains nothing (as shown by your ls -la command) makes no sense. To help diagnose it, the only idea I have: ls -dl .../paf (replace ... with the correct path to it). That will show us the link count of the directory itself, which might help debug why it isn't empty.

But most likely, the NTFS file system damage is of a kind that the ntfsfix program can't repair. I don't know whether NTFS support on FreeBSD is considered to be fully supported and bug-free, but you may just have found a bug in it (or rather, lack of a useful fsck for NTFS).
 
Back
Top