google-code-export / beets

Automatically exported from code.google.com/p/beets
MIT License
0 stars 0 forks source link

copy/move fails if destination is a remote filesystem mounted via SAMBA/CIFS and usernames do not match #383

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
As of b14, an import with import_move or import_copy appears to try and call 
os.utime on the file to update the timestamp, and subsequently fails. This 
appears to be related to the issue describe at 
http://www.samba.org/samba/docs/man/Samba-Developers-Guide/unix-smb.html

"The commonly used SMB protocols have no way of saying "you can't do that 
because you don't own the file". They have, in fact, no concept of file 
ownership at all.

This brings up all sorts of interesting problems. For example, when you copy a 
file to a unix drive, and the file is world writeable but owned by another user 
the file will transfer correctly but will receive the wrong date. This is 
because the utime() call under unix only succeeds for the owner of the file, or 
root, even if the file is world writeable. For security reasons Samba does all 
file operations as the validated user, not root, so the utime() fails. This can 
stuff up shared development diectories as programs like "make" will not get 
file time comparisons right.

There are several possible solutions to this problem, including username 
mapping, and forcing a specific username for particular shares."

So, if one has a remote SMB/CIFS share mounted as root (ie, via autofs), all 
files and directories will show root:root ownership, and the os.utime call will 
fail, even if the directory and files are word writable. Currently the only way 
to succesfully import/copy new files in this scenario is to run beets as root.

Original issue reported on code.google.com by rgl...@gmail.com on 13 May 2012 at 7:37

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for the detailed report. We should make some changes to silently fail 
the utime() call -- in our case, preserving the file modification time is "nice 
to have" but not essential. This will likely require reimplementing some of the 
functions in shutil.

Original comment by adrian.sampson on 13 May 2012 at 3:53

GoogleCodeExporter commented 9 years ago
This should be fixed as of 612c1f7b2602. Can you give it a try and see whether 
the issue is resolved for you?

Original comment by adrian.sampson on 19 May 2012 at 6:53