Subject: Huge unexpected file/dir deletions without user intervention

From: [email-masked] (Hans-Peter Jansen)
Date: Fri, 16 Jun 2000 02:59:24 +0200

Hi netatalk community,

once again, we got beaten by some strange effects
in an installation of 
Linux-i386-2.2.14-netatalk-1.4b2+asun2.1.4-3{7b|9}
and MacOS 9.04. It happened, that huge amounts of data got
deleted several times without reason! To be able to track 
down the problem, I kicked some syslog-messages into afpd.
Now, we can happily see, which user delete which files, but
cannot figure out, why it happens. There is Norton's antivir
installed on every box, but randomly, complete directory 
trees (around 2 GB) disappeared from the server. The concerned
users swear, they haven't triggered it, and didn't notice any
suspicious behavior.

I got bitten by this effect one day myself, while _moving_ some
dirs between two partitions. They simply _disappeared_, and had to
be restored from the original source. I'm sure, I _haven't_ 
_deleted_ them! (Too bad, the syslog messages weren't at this
time)

Does this effect relate to the caveat in man afpd:

       It is not possible to move directories between devices.

Does anybody suffered from those problems here?

Does somebody has some explanation for this effect?

They do work with the famous qxp 4.1r1 on local files (because
of well known file save problems of this poorgram(TM) on the server),
containing links to images on the server. (Mac alias problem?)

Thanks in advance

Cheers
Hans-Peter

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

---

From: Robert Bell <[email-masked]>
Date: Fri, 16 Jun 2000 09:29:21 -0700

Hans-Peter Jansen wrote:
>It happened, that huge amounts of data got
> deleted several times without reason!
...
> The concerned
...
> Does anybody suffered from those problems here?

Yes

> Does somebody has some explanation for this effect?

I have seem this behavior when I was trying to get the 
Network Trash Folder to work.
I never figured out why, 
but someone unrelated to the files would have a folder in their trash can.
If they did not pay attention when they emptied their trash can,
it could delete a lot of files when they personally only put a couple
of files (from a different folder) in the trash.
One user noticed that it was taking a long time to empty the network
trash can, and stopped it.  When we looked into their trash,
there was someone else's home folder in it.
That is when I changed the permissions on the "Network Trash Folder"
so that no files would go in it, and the user would get the message
when they deleted a file that it would get deleted immediately.

---

From: [email-masked] (Hans-Peter Jansen)
Date: Sun, 18 Jun 2000 16:21:21 +0200

> there was someone else's home folder in it.

Apart from the problem, this sounds like a /home permission problem. 
No user except root should be allowed to access other's home dirs.
Several distro's don't seem to be sensible about this concern.
chmod 700 /home/* does the job.

> when they deleted a file that it would get deleted immediately.

Okay, this sounds reasonable, because the user, who seems to be 
responsible for the deletions was the first one touching the freshly
created shares, and therefore able to store files in the trash...

My own deletion experience was in sync with experiments to get the 
trashcan working for more than one user, so it fits nicely into the
scenario.  

Let's conclude: don't let users move data the "Network Trash Folder",
otherwise, you are calling for trouble.

To Adrian: would you please temporarily disable the "Network Trash 
Folder" feature in the next release, until we know exactly, what 
happens and how we can fix this. It may be related to certain MacOS/
Finder versions. It happened with 9.04 in this case.
It's definitely a show stopper, if not worse...

Thanks for all responses. I'm able to give an explanation/fix to my
customer, as well as I hope, they will get back some confidence in
netatalk.

Cheers
FrisPete

-- 
"You can tune a filesystem but you can't tuna fish" (HP/UX' tunefs manpage)