Files saved (not new files) in TextEdit have mtime of 1 Jan 1970

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Mount a sshfs filesystem, I'm using -o ping_diskarb and the Finder seems to 
recognise it 
correctly
2. Create a new text file in TextEdit on the fs, save it.
3. Check that the modification time of the file is correct
4. Save the file again in TextEdit (maybe alter it to be sure it writes?)
5. Look at the modification time

What is the expected output? What do you see instead?
Expected time is the time it was saved a second time.

Actual time stored is 1 Jan 1970 (confirmed on the remote host).

What version of the product are you using? On what operating system?
svn r81, Mac OS X 10.4.8 Intel, fuse 2.6.1, sshfs 1.7 (with macfuse patches)

I've tried with -o cache=no, which makes no difference. I've attached debug 
output (-d -o 
sshfs_debug) for a file "1000". Note that the the first UTIMES line is me 
updating the time with 
"touch 1000".

I added a bit of extra debugging of mtime (see patch) in libfuse. The last call 
to GETATTR on the 
original file seems correct, but then the kext sends the fuse daemon "UTIMES 
SET mtime 0". I've 
looked at what utimes() call is being done by the Finder (using 
DYLD_INSERT_LIBRARIES) and it 
appears to be calling utimes() with a correct updated value. To me this would 
suggest that 
something is wrong with the setattr code in the kext? I couldn't see anything 
obvious from a 
glance over though.

Original issue reported on code.google.com by matt.gtalkfix@gmail.com on 16 Jan 2007 at 2:36

Attachments:

• sshfs.log1.gz
• fuse-debug-mtime.diff

[GoogleCodeExporter]

I have the same problem with TextMate on a PowerPC Mac

Original comment by mart...@gmail.com on 16 Jan 2007 at 3:05

[GoogleCodeExporter]

Original comment by si...@gmail.com on 17 Jan 2007 at 2:27

• Changed state: Accepted

[GoogleCodeExporter]

Looks like there's some variation of strange atime/mtime/ctime related behavior 
on remote/non-HFS+ file 
systems. Haven't had the time to do detailed debugging, but looks like TextEdit 
etc. do call utimes() with a "bad" 
tv[0] or tv[1] under certain circumstances. Try the same experiment on an NFS 
volume. Do a "stat -x" of the file 
in question before and after writing to it. Note the various time values.

Original comment by si...@gmail.com on 17 Jan 2007 at 8:43

[GoogleCodeExporter]

OK yeah, it does look like TextEdit is calling utimes() with a zero m_time (but 
correct atime). I can't see lstat() 
or similar returning any zero mtime values for the original file, and 
getattrlist() doesn't seem to be getting 
used for ATTR_CMN_MODTIME on sshfs paths. Maybe it's a Carbon File Manager 
issue?

The call:
utimes path '/Users/matt/mnt/ucc/tmp/1000', atime sec 1169041147 usec 0, mtime 
sec 0 usec 0

Trying with NFS, I'm seeing strange behaviour where the atime starts at 1 and 
then increases by 1 each time 
for every utimes() on that fs. The counter even persists between mounts. I have 
a suspicion that it could be 
the linux NFS server though. The mtime always seems correct for NFS - probably 
not the same thing as sshfs?

utimes path '/Users/matt/mnt/drone-nfs/2000', atime sec 8 usec 0, mtime sec 
1169040202 usec 0

I've attached the dyld preload library hack I'm using.

sshfs before:
  File: "1000"
  Size: 17           FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (11154/ (11154))  Gid: (    0/   wheel)
Device: 44,39   Inode: 651    Links: 1
Access: Wed Jan 17 22:28:20 2007
Modify: Wed Jan 17 22:28:20 2007
Change: Thu Jan  1 08:00:00 1970

sshfs after:
  File: "1000"
  Size: 19           FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (11154/ (11154))  Gid: (    0/   wheel)
Device: 44,39   Inode: 803    Links: 1
Access: Wed Jan 17 22:39:07 2007
Modify: Thu Jan  1 08:00:00 1970
Change: Thu Jan  1 08:00:00 1970

nfs before:
  File: "2000"
  Size: 16           FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (  501/    matt)  Gid: (  501/    matt)
Device: 26,40   Inode: 4849975    Links: 1
Access: Wed Jan 17 22:22:34 2007
Modify: Wed Jan 17 22:22:34 2007
Change: Wed Jan 17 22:22:34 2007

nfs after:
  File: "2000"
  Size: 18           FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (  501/    matt)  Gid: (  501/    matt)
Device: 26,40   Inode: 4849976    Links: 1
Access: Thu Jan  1 08:00:08 1970
Modify: Wed Jan 17 22:23:22 2007
Change: Wed Jan 17 22:23:23 2007

Original comment by matt.gtalkfix@gmail.com on 17 Jan 2007 at 1:49

Attachments:

• fakeutimes.c

[GoogleCodeExporter]

I noticed this behavior in JEdit as well.  I ran a 'touch filename' on my client
machine terminal in my mounted sshfs dir and it updated the modified date to the
correct date and time.

Saved in JEdit:

 stat -x File.php
  File: "File.php"
  Size: 14401        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (  523/   (523))  Gid: (  524/   (524))
Device: 44,7   Inode: 692    Links: 1
Access: Wed Jan 17 11:30:36 2007
Modify: Wed Dec 31 19:00:00 1969
Change: Wed Dec 31 19:00:00 1969

# touch File.php

 stat -x File.php
  File: "File.php"
  Size: 14401        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (  523/   (523))  Gid: (  524/   (524))
Device: 44,7   Inode: 692    Links: 1
Access: Wed Jan 17 11:33:02 2007
Modify: Wed Jan 17 11:33:02 2007
Change: Wed Dec 31 19:00:00 1969

Original comment by steve.b...@gmail.com on 17 Jan 2007 at 4:35

[GoogleCodeExporter]

Something to try: in the kext source, please see if commenting out the line 
containing ATTR_CMN_MODTIME in 
fuse_vfsops.c changes the behavior.

Original comment by si...@gmail.com on 17 Jan 2007 at 5:32

[GoogleCodeExporter]

ATTR_CMN_MODTIME is commented out in the current source version.  It appears 
the issue is resolved when 
compiled from the repository.

Great Work!

Original comment by bern...@gmail.com on 18 Jan 2007 at 6:50

[GoogleCodeExporter]

Commenting out ATTR_CMN_MODTIME fixed the problem for me too. 

Excellent stuff

Original comment by mart...@gmail.com on 18 Jan 2007 at 3:04

[GoogleCodeExporter]

Original comment by si...@gmail.com on 19 Jan 2007 at 8:35

• Changed state: Fixed