Bug 3752 - rsync unusable with EncFS filesystem
rsync unusable with EncFS filesystem
Status: RESOLVED WONTFIX
Product: rsync
Classification: Unclassified
Component: core
2.6.8
x86 Linux
: P3 critical
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-04 12:23 UTC by micheal ah fat
Modified: 2009-05-03 20:05 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description micheal ah fat 2006-05-04 12:23:25 UTC
Hi

I've just installed EncFS...  Looks like RSYNC does not set the file timestamp to the original timestamp...  In fact,  it is set to the current time.

So, the next time RSYNC is run,  it just copies all the files.

Have downloaded the source & tried to figure out what's causing the problem.

The timestamp is set properly after finish_transfer().  However, it gets reset after 8 files have been copied; i.e after 8 files have been copied, the time stamp of the 1st copied file is reset... after 9 files, 2nd file get reset, 10 files, 3rd file get reset & so on.

Looks like the problem is somewhere in recv_files() / receive_data()...  Could not pinpoint as the 'reset' does not seem to happen at a fixed point.

Have searched the net & have not found anyone having the same problem... So may be I'm doing something wrong.

Would appreciate your help on this matter.

Micheal
Comment 1 Wayne Davison 2006-05-05 01:28:54 UTC
After rsync sets the time/attributes on a file, it renames the file into place and it is done with it.  If the timestamp is changing after that, I have a hard time imaging that this is rsync's fault.  You might want to test that the renaming of a file can be done without having EncFS change the file's modify time (it shouldn't).
Comment 2 micheal ah fat 2006-05-05 13:39:44 UTC
The problem is indeed with EncFS/FUSE...  e.g mv xxx yyy changes the mod time

Solved by modifying "syscall.c"

int do_rename(const char *fname1, const char *fname2)
{
	if (dry_run) return 0;
	RETURN_ERROR_IF_RO_OR_LO;
//	return rename(fname1, fname2);
 {
	int x1;
	struct stat s1;
	x1 = stat(fname1, &s1);
	if (x1 != 0)
		return x1;
	x1 = rename(fname1, fname2);
	if (x1 != 0)
		return x1;
	return set_modtime(fname2, s1.st_mtime, s1.st_mode);
 }
}
Comment 3 micheal ah fat 2006-05-05 13:40:57 UTC
.
Comment 4 micheal ah fat 2009-05-03 11:44:09 UTC
(In reply to comment #2)
> The problem is indeed with EncFS/FUSE...  e.g mv xxx yyy changes the mod time
> 
> Solved by modifying "syscall.c"
> 
> int do_rename(const char *fname1, const char *fname2)
> {
>         if (dry_run) return 0;
>         RETURN_ERROR_IF_RO_OR_LO;
> //      return rename(fname1, fname2);
>  {
>         int x1;
>         struct stat s1;
>         x1 = stat(fname1, &s1);
>         if (x1 != 0)
>                 return x1;
>         x1 = rename(fname1, fname2);
>         if (x1 != 0)
>                 return x1;
>         return set_modtime(fname2, s1.st_mtime, s1.st_mode);
>  }
> }
> 

I can confirm the bug has not been fixed in rsync 3.0.5 & encfs 1.4.2.

The patch still works with rsync 3.0.5

Download source from http://www.samba.org/ftp/rsync/src/rsync-3.0.5.tar.gz

Extract to /tmp
cd /tmp
vi syscall.c
Search for do_rename. Apply patch & save
./configure
make install
cp /usr/local/bin/rysnc /usr/bin


Comment 5 Wayne Davison 2009-05-03 20:04:40 UTC
This is not a bug in rsync, but a bug in EncFS.  While you created a work-around that does several extra calls per rename in the rsync source, those calls would not be appropriate for general use and will never appear in an rsync release.  Also, this bug should not have been closed as "Fixed", so I'll reopen it and close it again.
Comment 6 Wayne Davison 2009-05-03 20:05:18 UTC
I'd suggest that you go into the EncFS source and fix it so that a rename doesn't change the mtime for a file.