Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a sample NAS server (QNAP TS-210), with very limited Linux on-board (although a bit reinforced with Optware/IPKG). I'm a Linux newbie. After digging through Internet I was able to write my own backup script, using rsync for syncing files between NAS hard drive and external USB drives, and with CRON for running this script periodically.

Everything was fine until few days before. E-mails generated by backup script started containing information IO error encountered -- skipping file deletion for many resources (folders) being backed up. When I run the very same script via SSH I got a lot of error lines saying "cannot send file with empty name in...", followed by "rsync error: some files/attrs were not transferred (see previous errors)".

100% of content I'm backing-up comes from Windows (I use NAS only to backup my own computers). This system does not allows to create a file with empty name. This problem exists for only few days and I was not modyfing my backups for over a few weeks (vacation). So this has to be Linux (on-board my NAS) issue.

Question is: what can cause files to appear with empty names? How can I get rid of them (when I cd to folder mentioned in rsync report, and do ls -ls, I see nothing like "file with an empty name"), so next rsync pass would end up without such errors. And finally -- how to avoid getting such files in future?

share|improve this question
1  
Please add some more details to your question. Copy the script into the question and give us the filenames that rsync doesn't like. –  jippie Jul 4 '12 at 16:56
    
@jippie: (1) Script is to long to paste, and this is not necessary. It is really simple. It contains only: preparation of text file, serie of calls to rsync (like that: /usr/bin/rsync --archive --delete --whole-file --verbose --human-readable --cvs-exclude --update --log-file="/backup/hp/docs.log" "/share/MD0_DATA/Docs" /backup/hp/ >> $MAILFILE) with throwing rsync results to that text file, e-mailing me that text file and deleting it. I even resigned from loop, because I had to many strange problems with it (lack of knowledge?) and replaced it with serie of rsync calls. –  trejder Jul 5 '12 at 8:01
    
@jippie: (2) How can I give you filenames that rsync dosen't like, if we're talking about files without a name? :] I can only provide you with paths, where it finds these files. But these are just ordinary folders with docs, mp3, movies and this kind of data (multimedia) that I backup. –  trejder Jul 5 '12 at 8:03
    
@warl0ck: What are you talking about? ALL the error messages, that I get from rsync are already mentioned in the question. There are two kinds of error messages: "cannot send file with empty name in...", followed by "rsync error: some files/attrs were not transferred (see previous errors)". Nothing else. –  trejder Jul 5 '12 at 8:04
    
I've had tons of troubles with Windows equivalent for symbolic links. Don't know what they're called on Windows. All files must have a name, make sure you haven't got hidden files in those directories. If you know what files are successfully backup'ed, then you know whicht files aren't. –  jippie Jul 5 '12 at 8:17
show 1 more comment

1 Answer

up vote 2 down vote accepted

I don't think this is rsync's fault. I think you've correctly tagged this as a kernel-level issue, since the relevant code from rsync's flist.c sources reads:

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

In fact, that line of code was added by rsync developer back in August 2007 specifically for this case:

If readdir() gives us an empty name, reject it.

In other words, readdir() itself (the kernel function that returns the list of files in a directory) returned an entry with an empty string. Under the rules, that's never supposed to happen. Quoting from the Open Group spec:

The readdir() function shall not return directory entries containing empty names.

It sounds like it was some kind of transient problem, because it was gone by the time you did an ls in that directory (which would have also used readdir(), it was gone).

So the answer to your questions:

  1. Cause appears to be a corrupted filesystem - anything from kernel driver bug to hardware fault could be responsible. May also be worth checking if the directory you're rsync'ing over is accessed via symlink or crosses a network boundary itself that may be having problems.

  2. To get rid of them: the usual filesystem repair checklist: fsck, etc.

  3. To avoid in the future: I suppose you could tell your script to force a recursive listing beforehand - but since you're already getting noticed (and you're back from vacation) it seems the right thing to do is to keep an eye on it and jump on the box if it happens again.

Hope this was useful, good luck!

share|improve this answer
    
Out of fsck group I have only e2fsck available on my machine. Am I right, that it can only check 'ext2' paritions? Since all other options failed, I have to format my external hard disk, but NAS gives me only ext3 and ext4 options. Does it means, that even after formatting I'll again stay with no tool for checking file system? –  trejder Jul 26 '12 at 20:25
1  
@trejder regarding e2fsck: 1. Have you checked for all possible fsck programs? ls -l /sbin/*fsck*|sort 2. Have you checked the man page for ext3 functionality? man e2fsck | grep ext3 e2fsck –  user34922 Mar 26 '13 at 0:41
    
No and no! :] I've just checked with your command in both sbin and bin folders and e2fsck is the only one, I have there. As for man -- this command has been removed from my very limited distro (this is NAS, not Linux, and creators seems to assume, that user should not use it at all via shell). –  trejder Mar 27 '13 at 11:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.