Bug 9966 - Problems renaming files on AUFS
Problems renaming files on AUFS
Status: RESOLVED INVALID
Product: Samba 3.6
Classification: Unclassified
Component: File services
3.6.3
All All
: P5 enhancement
: ---
Assigned To: Björn Jacke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-22 14:15 UTC by Christian Huldt
Modified: 2013-06-25 08:39 UTC (History)
0 users

See Also:


Attachments
level 10 debug log trying to rename a file on aufs (341.67 KB, application/octet-stream)
2013-06-22 14:15 UTC, Christian Huldt
no flags Details
level 10 go of renaming a file not on aufs on the same server (110.14 KB, text/plain)
2013-06-22 14:17 UTC, Christian Huldt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Huldt 2013-06-22 14:15:45 UTC
Created attachment 8989 [details]
level 10 debug log trying to rename a file on aufs

I thought I could provide a smooth transition from traditional hard
drives to ssd by layering the ssd on top of the existing file
structure with aufs [1].

Unfortunately folders with content not completely copied up to the
ssd can not be renamed through samba. Renaming (mv) on the server
works flawlessly, and afterwards that folder is copied up to the ssd
and renaming works from windows, but before that, windows7 returns
"invalid device" and smbclient says "access denied". To do an rename
from windows requires copying the folder to the client, deleting it
from the server and copying it back, then it works, as the folder is
now on the ssd.

[1] http://aufs.sf.net
Comment 1 Christian Huldt 2013-06-22 14:17:41 UTC
Created attachment 8990 [details]
level 10 go of renaming a file not on aufs on the same server
Comment 2 Christian Huldt 2013-06-24 17:28:51 UTC
Got this from the developer of aufs:

Christian Huldt:
> Yes, this sounds very reasonable, the human readable error message is
> "NT_STATUS_NOT_SAME_DEVICE"
>
> Does that mean that I should kill the bug?
> I'm not knowledgeable enough to now if this is a requirement for being a
> POSIX compliant filesystem.

This behaviour is not POSIX (or SUSvX) compliant. It is a feature of
aufs and any other stackable filesystems.
It may be good to tell the samba developer.

If you really want to change the behaviour, you need to modify the
source files of samba, and support the EXDEV error from rename(2)
systemcall, I am afraid.
Comment 3 Björn Jacke 2013-06-25 08:39:10 UTC
the behaviour is intended. Have a look at the crossrename vfs module. If you cannot improve aufs to be more transparent then crossrename might help. you will lose ACLs and other things however. If you wanna improve crossrename to support to retain ACLs and other meta data, patches are welcome here, too. I'll close this one as INVALID because samba has to reply NT_STATUS_NOT_SAME_DEVICE in cases like this, Windows does the same btw.