Move files to Trush from Server

Question

I have set up a Mac OS X Server 10.4.6; and i share caple of Volumes to Mac OS X, Mac OS 9 & WinXP.
So my problem is when i move somthing to Trush from OS X, a window apears to say "The item .... will be deleted immediatly. Are you sure you want to continue? if i press OK then the file will delete. This dos not hapen with OS 9. can you help me???
I wont to move my files first to Trash and when i decide to emty my trash the file will delte.

Answer 1

are these AFP shares or SMB shares?
anyway, i found an excellent writeup on these issues on the macintouch site.... copy/pasting:
There are some subtleties that actually determine the exact behavior of Macs when it comes to trashing files on Network volumes for both Mac OS X and Mac OS 9 and earlier.
All of the different behaviors comes back to one basic question - where does the file moved to the trash go? Remember, the Trash Can is just a directory (actually, the summation of several directories) where files get moved to. There has to be a different one for each volume that is mounted so that you don't have to copy a file from one volume to another volume to put something in the trash - hence your "Trash Can" actually reflects the contents of these different directories on different volumes. I believe (though I can't prove it) that even when dealing with network mounted volumes this is a client decision, not a file server decision. The file server (regardless of the OS running) just gets a request to move a file from point A to point B - it doesn't know that this file is being "trashed".
In Mac OS 9 and earlier for local volumes, there was just one directory to hold trash for that volume. Mac OS 9 and earlier didn't have the concept of multiple users (without additional software at least, and these were essentially nasty contortions to "fake it"). For network volumes there was a scheme for creating an invisible Network Trash folder on the root level of the Share. I don't know how it handled multiple users logging into the same share (and am not going to spend the time to figure out - I believe it had to do with actually having multiple Trash Can folders within the Network Network Trash folder). So, if you had write permissions to the root level of the share you could create this folder (if it didn't already exist) and the client Mac would move the trashed file there. However, it would insist (at least is some cases - again, don't know all the details) on emptying this folders contents (your trash) when you went to dismount the network volume. However, if you didn't have write permissions to the Network Trash folder or to the root level of the share to create a Network Trash folder, you would get the message that the file would need to be deleted immediately.
In Mac OS X Apple had to change the scheme as we are now in a multi-user environment - there are many different "trash can" directories. Each user gets one in .Trashes at the root level of their home directory (whether it be a local disk home directory or a network mounted home directory). There is also a .Trashes at the root level of all volumes mounted. Inside of this root level of the volume .Trashes directory is a folder with a number on it (the number is the UID - user id which - each login actually maps to one of these, remember that computers do numbers so we are all a number to them . So, if I delete an item off of a Firewire hard drive that I have plugged in, the file gets moved to the .Trashes/{UID number} at the root level of that Firewire drive. Since each user has a unique UID, we also have unique trash cans - that in our home directory .Trashes, and then in the volume based .Trashes it is in the folder /.Trashes/{UID}.
Now we turn to Mac OS X with network volumes. It would appear that Apple doesn't even try to create a .Trashes/{UID} at the root level of network shares. It just insists on deleting the file immediately if it is on a network share. I am not quite sure of why this decision was made, but it does make things much cleaner from a system administration standpoint. Think about a network share that 2000 different users have access to (and yes I have those - we have about 80,000 users of our servers across around 180 "shares" that is a lot of trash cans OUTSIDE of the users directory (since it must be at the root level of the share) that they have permission to write to and can have files in. That breaks entirely the paradigm of keeping all user writable spaces in one place. Now, this doesn't apply when you mount the volume as a home directory since it uses the .Trashes directory at the root level of the USER'S HOME directory, NOT the root level of the share. If you don't understand the difference between these two situations (mounting as a share and mounting as a home directory), ask someone who programs or does system administration .
Now, since this is a client decision, the Mac OS 9 client will move it to a writable Network Trash directory if one exists while Mac OS X clients won't even try even when the two are looking at the same file server. This is why you get different behavior to the same share depending on the client OS version. However, if the user doesn't have write permission to the Network Trashes folder at the root of the share, Mac OS 9 and earlier will now behave like Mac OS X - delete immediately.
There is one place where I get different results than what Alex Narvey described. When I mount the space via SMB with a Mac OS Xclient, I get the SAME behavior as I did when I mounted that same space via AFP. Now, if you are going via SMB to a different kind of file server (namely, a Windows one) that might explain the different behavior, but I tend to doubt it. As I said above, I believe how to move things to trash is a client decision/behavior, not server (and as I said above - I can't prove that). So, I don't have an explanation for the difference between the behavior I see and the behavior Alex described.
Long, but hopefully educational. Doesn't explain WHY Apple made the decision they did, but should give one a better understanding of the different behaviors that can occur. Like in science, it is important to remember that different behaviors occur because something IS different. Now, perhaps Apple should make the behaviors the same (from a user standpoint) even when things are different (like what kind of volume are we dealing with, who has write permissions to where, etc). - that I will duck. That is an argument between a human interface designer and the programmer who actually has to try and make it work.
Following up on my own post -
It just dawned on me WHY Apple would make Mac OS X always ask to immediately delete a file off a network share, rather than trash it.
For consistency of the user experience when dealing with network shares. In Mac OS 9 and earlier whether you could move a file to the trash or if you had to delete immediately depended on the SERVER and write permissions there on the server. So, on Mac OS 9 and earlier you would get different behavior and have no real idea why you got different behavior.
The Mac OS X behavior is different from that of Mac OS 9 and earlier, but within itself, it is very consistent - for network volumes you are always asked to delete the file immediately. This means that the user has a consistent user experience when at that Mac, regardless of the type of server or their permissions on the different network shares they may work with. If this is why Apple made the change in OS X, I would agree with them. Consistency is more important than features (as a general statement).