Subject: Modification Dates in netatalk and samba

From: Jan Dockx <[email-masked]>
Date: Tue, 10 Oct 2000 23:39:44 +0200

We have a problem with modification dates on our linux/netatalk/samba 
setup. We observed 2 strange phenomena today:

Somebody changed html files on the server this morning with a text 
editor from Windows, via Samba. When we looked at the file 
modification dates with a shell or via netatalk, or via the Windows 
Properties window, the modification date was still yesterday evening, 
i.e., the last time the files were changed from a Mac through 
netatalk. The contents of the file was changed however.

Later today, we did a touch on the files via a shell. The 
modification dates changed, we saw through the shell. The 
modification dates also appeared changed via the Windows Properties 
window. From a Mac however, in the Finder or in another application 
(DreamWeaver), the files still showed a Modification Date of 
yesterday evening.

Unmounting all volumes served from the server didn't help. We 
restarted the entire machine, an repeated the experiments. Same 
results.

The only way we could get the modification date to change on a Mac, 
was by editing the files from a Mac through netatalk. The 
modification date changed on the server (shell), on Windows (samba) 
and on Mac (netatalk).

Then we thought that the modification date for Mac's might come from 
the resource-fork-files in the .AppleDouble folder. But this didn't 
fit the bill either.

Do we have 2 separate problems? It seems pretty amazing that samba 
would be able to change files without changing the modification date. 
Does samba bypass the unix file system? Does netatalk cache 
modification dates somewhere? Very hard, then?

Please reply if you have encountered this strange behavior too, or if 
you know how either samba or netatalk deals with modification dates.
-- 

Jan Dockx - assistent               ([email-masked])
K.U.Leuven, Department of Computer Science
Celestijnenlaan 200 A 03.28; 3001 Heverlee; Belgium
tel.: ++ 32/16/32 76 56                   fax.: ++ 32/16/32 79 96
<http://www.cs.kuleuven.ac.be/~jand/>
+---------------------------------------------------------------+
"I think I have figured out Microsoft's major plans for Win 2000.
  No longer will Microsoft's NT offer only a Blue Screen of Death.
  Microsoft will now offer the 'Screen of Death' in 5 colors."
                                                       David Puett

---

From: Tom Kacvinsky <[email-masked]>
Date: Tue, 10 Oct 2000 17:57:48 -0400 (EDT)

> the resource-fork-files in the .AppleDouble folder. But this didn't 

Yes, it does.  The files sitting in the .AppleDouble directories have timestamp
information embedded in them.  Looking at my AppleDouble documentation, it is
entry descriptor 8.

Touching these files will not change the timestamp info in the file, and I know
of no tool that will do (though one could be cooked up easily enough).

I guess Samba's netatalk integration doesn't take this into account.  Bummer.

Tom

---

From: Jan Dockx <[email-masked]>
Date: Wed, 11 Oct 2000 10:23:26 +0200

Thanks.
Seems to me netatalk is the one at fault, not samba. When serving 
files, netatalk should be more intelligent. It should strip the entry 
descriptor 8 you talk about from the resource, and transmit the file 
system time stamps instead.
Otherwise file changes through samba would present the correct time 
stamps on a Mac, but not file changes done from unix.

High time I got some time to program some things for netatalk :~$.

So, that mystery is solved. The other problem seems to be purely 
samba, so this is probably not the best mailing list to pursue it 
further.

--

---

From: Tom Kacvinsky <[email-masked]>
Date: Wed, 11 Oct 2000 10:01:33 -0400 (EDT)

Hi,

I made a mistake.  netatalk uses version AppleDouble files, and the mac file
info/timestamp information is stored in entry descriptor 7.

The AppleDouble documentation I have (version 2) specifies that version 1 files
can be updated to version 2 files by replacing id 7 with id 8 (time stamp info)
and one of the following entry IDs: Macintosh File Info (ID=10), ProDOS File
Info (ID=11), or MS-DOS File Info (ID=12).

There is some conditional code in asun's version for version 2 AD support, but
it isn't turned on because the persistent DID stuff is not yet complete.

I have asked about when the DID stuff will be completed, but I haven't heard
back.

Tom

---

From: Tom Kacvinsky <[email-masked]>
Date: Wed, 11 Oct 2000 10:55:21 -0400 (EDT)

Entry id 14 (AFP info) is also used...

More information in include/atalk/adouble.h...

Tom

---

From: Bob Rogers <[email-masked]>
Date: Wed, 11 Oct 2000 12:56:34 -0400 (EDT)

From: Jan Dockx <[email-masked]>
   Date: Wed, 11 Oct 2000 10:23:26 +0200

   Thanks.

   Seems to me netatalk is the one at fault, not samba. When serving 
   files, netatalk should be more intelligent. It should strip the entry 
   descriptor 8 you talk about from the resource, and transmit the file 
   system time stamps instead . . .

   High time I got some time to program some things for netatalk :~$
   . . .

   Jan Dockx

If a rationalization of the way netatalk deals with timestamping is in
prospect, I would like to add the following request.

   When I copy folders in the Finder from a Mac local disk to a netatalk
share (using afp/tcp, btw), the Finder (apparently) dutifully sets the
file modification date to that of the original Mac file, so that "ls -l"
on the Linux box shows the original file date, as you would expect.
However, the .AppleDouble file always keeps the current date, and
therefore looks much more recently modified than the data fork file.  It
seems to me that, when told to set the modification date for a file,
afpd should also set the .AppleDouble mod date as well.

   I suppose this is a rather nitpicky detail (I confess I am embarassed
to explain why I care), but since changing both dates is reasonable,
consistent, and useful (to me, at least), I thought I should pipe up.

   Comments?

					-- Bob Rogers