Bug 5431 - rename fails when newpath is open and deletes newpath
Summary: rename fails when newpath is open and deletes newpath
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P3 regression
Target Milestone: ---
Assignee: Jeff Layton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-30 04:28 UTC by Peter Parzer
Modified: 2008-11-23 07:39 UTC (History)
0 users

See Also:


Attachments
test program by Wilhelm Meier (847 bytes, text/plain)
2008-08-30 05:51 UTC, Jeff Layton
no flags Details
kmail patch for this bug (501 bytes, patch)
2008-08-31 06:39 UTC, Wilhelm Meier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Parzer 2008-04-30 04:28:09 UTC
The rename(oldpath, newpath) system call on an cifs mounted partition fails when newpath exists and is open. The existing file newpath is deleted. This prevents kmail from creating maildir folders on cifs mounted filesystem (because of sloppy programming on kmail's side). Here is a part from the strace:

# open .inbox.index

open("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 13 
utime("/home/parzerpeter/.kde/share/apps/kmail/mail/inbox", NULL) = 0 
utime("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index", NULL) = 0 
utime("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index.ids", NULL) = -1 ENOENT (No such file or directory) 
umask(022)                              = 077 
fcntl64(13, F_SETFD, FD_CLOEXEC)        = 0 
unlink("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index.temp") = -1 ENOENT (No such file or directory) 
utime("/home/parzerpeter/.kde/share/apps/kmail/mail/inbox", NULL) = 0 
umask(077)                              = 022 
open .inbox.index.temp (fd=14), .inbox.index is still open 
open("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index.temp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14 
umask(022)                              = 077 
fstat64(14, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 
mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb550e000 
write(14, "# KMail-Index V1506\n\0\10\0\0\0xV4\22\4\0\0"..., 33) = 33 
 _llseek(14, 0, [33], SEEK_CUR)          = 0 
fsync(14)                               = 0 
close(14)                               = 0 
munmap(0xb550e000, 16384)               = 0 
rename("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index.temp", "/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index") = -1 EINVAL (Invalid argument) 
 
# try to rename inbox.index.temp to .inbox.index, rename fails, 
# maybe because .inbox.index is still open (fd=13)
 
close(13)                               = 0 
open("/home/parzerpeter/.kde/share/apps/kmail/mail/.inbox.index", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory) 
 
# open fails, because .inbox.index is deleted 
 
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Comment 1 Jeff Layton 2008-08-30 05:51:57 UTC
Created attachment 3516 [details]
test program by Wilhelm Meier
Comment 2 Jeff Layton 2008-08-30 05:56:33 UTC
With this test program and testing against a netapp, I see an ENOENT error rather than EINVAL:

rename("/mnt/netapp-cifs/jlayton/rawhide/rename-test", "/mnt/netapp-cifs/jlayton/rawhide/rename-test.r") = -1 ENOENT (No such file or directory)

...still though, it doesn't work...
Comment 3 Wilhelm Meier 2008-08-31 06:39:07 UTC
Created attachment 3517 [details]
kmail patch for this bug

This patch makes kmail happy. If first closes the open file before renaming to it.
Comment 4 Jeff Layton 2008-11-23 07:39:48 UTC
I think this is now resolved to the best of our ability in mainline kernels, at least when talking to windows. netapp servers do not implement the calls to handle busy-file renames however.

Marking this resolved since it seems to now be...