When copying folders containing veto files to a Netatalk volume, the copy will fail with an error code -50 on the Mac. The user on the Mac has no indication why the copy failed and is probably not even aware of such a thing as vetoed files.
What can be done to enhance the user experience? Could the copy request for the veto file simply be ignored by the server such that the rest of the copy could proceed?
Vetoing a file does two things: first if such a file exists on the NAS it is hidden from
the Mac. Second, any attempt to use any filesystem operation (eg create, stat, open) is
So when the client tries top copy a file with a vetoed name to the server, it would issue
the following (simplified) series of syscalls that translate to certain AFP protocol
1) check if the file already exists
2) if it doesn't exist, create it
3) stat it
4) modify certain file attributes, eg the file time stamps
4) open filehandle for writing
5) write to filehandle
6) close filehandle
Now in order to achieve the desired result of a vetoed filename while still allowing the client to proceed with the copy operation, the server would need to pretend all of the above operations succeeded, maintain state and return artificial information to the client. Implementing such modifications may be possible, but at the high risk of introducing bugs.
The following solution may be an helpful alternative: whenever a client tries to access/create a vetoed file, a message is sent to client displaying the vetoed name and the name of the parent folder.