Bug 2768 - Copying veto files to server generates not found error.
Copying veto files to server generates not found error.
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-06-03 13:26 UTC by Jason Hoover
Modified: 2006-06-07 14:23 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jason Hoover 2005-06-03 13:26:26 UTC
When "veto files" is set to (for example):

veto files = .AppleDouble/._*/.DS_store

Copying already-existing files like "._foobar" will cause errors instead of just
failing silently.

For example:

From *nix with smbclient:

smb: \profile\Desktop\> put "._foobar" "._foobar"
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \profile\Desktop\._foobar

Or from windows:

Jun  2 13:35:18 WORKSTATION Userenv: DOMAIN\user: Windows cannot copy file
C:\Documents and Settings\user\Desktop\._foobar to location
\\SERVER\user\profile\Desktop\._foobar. Contact your network administrator.
DETAIL - Cannot create a file when that file already exists.

This will cause roaming profiles to abort unloading if you set the option on an
existing setup. This can cause a bit of chaos when you choose to set this option
on files like .DS_store to reduce clutter.

Please grapeshot accordingly if duplicate/already fixed.
Comment 1 Damien Sorresso 2006-06-07 14:23:46 UTC
I can confirm this bug on a Gentoo Linux server with Samba 3.0.14. If a share is set up to veto dot-files, Mac OS X users will be unable to copy any files over to the share through the GUI; they will have to use the command line. This is because, when copying a file to a non-HFS file system, Mac OS X preserves the file's metadata by writing an invisible dot-file with the name "._<filename>". When the OS X attempts to write this during a copy to a Samba volume, Samba returns an error saying that the file name is bad.

This also happens on Windows if the user tries copying a directory containing a dot-file (or a dot-file directly, if the user is viewing hidden files).

I was debating with a co-worker as to whether this is really an OS issue or a Samba issue. Of course, Samba is acting exactly how it should. Vetoing files has the effect of denying both visibility AND access. Should the Samba server allow writes of files with vetoed names and then simply veto them once the write is done?