[Pkg-samba-maint] Bug#653207: #653207 (smbclient: Smbclient 3.6.1 incompatible with BackupPC 3.2.1) said to be fixed upstream with 3.6.6, but 3.6.6-2 still shows the same problem

[Axel Beckert]

Hi again :-)

some more braindump about this issue...

Axel Beckert wrote:
> According to WHATSNEW.txt in the source package of 3.6.6-2, the
> upstream bug for #653207 has been fixed with 3.6.6:
> 
>     * BUG 8922: smbclient's tarmode insists on listing excluded directories.
> 
> I could also assure myself that the fix attached to the upstream bug
> is part of the 3.6.6-2 source package.
> 
> But I can still reproduce this issue on Wheezy with 3.6.6-2:
> 
> Using tarmode still results in aborted transfers:
> 
> $ smbclient \\\\[...]\\C\$ somepassword -U backuppc -d 10 -E -c tarmode\ full -Tc test2.tar
> [...]
> (26.8555 kb/s) (average 7605.74 kb/s)
> dos_clean_name [\boot.ini]
> unix_clean_name [\boot.ini]
> NT_STATUS_ACCESS_DENIED opening remote file \boot.ini (\)
> lang_tdb_init: /usr/share/samba/en_US.UTF-8.msg: No such file or directory
> NT_STATUS_ACCESS_DENIED listing \\*
> tar: dumped 163 files and directories
> Total bytes written: 7737856
> 
> The command above works as expected on Debian Squeeze with smbclient
> 2:3.5.6~dfsg-3squeeze6:
> 
> [...]
> (53.7109 kb/s) (average 7926.66 kb/s)
> dos_clean_name [\boot.ini]
> unix_clean_name [\boot.ini]
> NT_STATUS_ACCESS_DENIED opening remote file \boot.ini (\)
> strlen(cur_dir)=1, strlen(finfo->name)=26
> [...]
> 
> So it looks as if the upstream fix is either incomplete (in that case
> I'd be happy if someone could reopen the bug upstream) or there are
> actually two different issues.

The longer I think about this issue, the more I'm convinced that there
should be an option to switch between the new behaviour (abort on
first unreadable file) and the old behaviour (continue, but report
unreadable files on STDERR).

Both modes have a valid motivation and use cases:

The old one as it's the more pragmatic one and the new one which makes
sure that all files which should have been in the tar ball are in the
tar ball.

Nevertheless the old mode is definitely needed, because BackupPC will
become quite inefficient because it first has to either generate a
dynamic blacklist of files it won't be able to transfer or transfer
each file separately.

While the administrator could generate a hardcoded blacklist of files
which can never be backed up, this doesn't work for often locked files
which should be backed up occassionally anyway like outlook.pst.

BackupPC even has some specific routines to inform users if backups in
general were fine, but the .pst files were locked. With the current
smbclient version, now all backups would fail of Outlook is running.
(Haven't checked if BackupPC already has a dynamic blacklist for a
second run after an aborted tarmode due to locked outlook.pst files.
But that would be quite inefficient.)

P.S.: Even though smbclient's tarmode aborts currently on unreadable
files, smbclient's exit code is still zero, which indicates success on
unixish systems. It should exit with a non-zero in this case.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5