2014-01-06 8 views
44

Die Codebasen, mit denen ich arbeite, werden von Git-Repositories auf meinem Linux-Rechner ausgecheckt. Da unser Produktionscode für den Einsatz unter Linux geschrieben wurde, mache ich alle Tests auf meinem Linux-Rechner, nutze aber Windows für den täglichen Gebrauch, einschließlich Code-Bearbeitung/Authoring.Dateiberechtigungen für Samba-Freigaben erhalten, wenn Datei bearbeitet wird

Zu diesem Zweck habe, habe ich eine Samba-Freigabe des Ordners (mein Home-Ordner), wo ich den Code, wie diese Kasse:

[wgrover] 
    path = /home/wgrover 
    available = yes 
    valid users = wgrover 
    read only = no 
    browsable = yes 
    public = yes 
    writable = yes 

Allerdings, wenn ich eine Datei aus dem Bearbeiten Samba teilen \\linux-box\wgrover in Windows, die Dateiberechtigung in Linux ändert sich weiterhin zu 755, obwohl es 644 vor der Bearbeitung war.

Dies hält in meinem git diff wie dies zeigt sich:

diff --git a/debian/maggie.nginx.conf b/debian/maggie.nginx.conf 
old mode 100644 
new mode 100755 
index 7cda506..7eab574 

Es ist möglich, eine create mask in smb.conf zu setzen, aber das wird auch nicht „bewahren“ die ursprünglichen Dateiberechtigungen. Ich kann Dateimodusänderungen in git ignorieren, indem ich fileMode = false in .gitconfig einstelle, aber das ignoriert auch das Problem.

Gibt es eine Möglichkeit, die Dateiberechtigungen beizubehalten, wenn sie von Linux geändert werden?

+0

meine /etc/login.defs sagt 'UMASK 022', dass relevant ist? – recognosco

+0

@ElliottFrisch Ich habe versucht, mit dem Umask-Wert herumzuspielen, aber keinen Erfolg. Haben Sie irgendwelche Hinweise auf die Dokumentation, die Sie gesehen haben? – recognosco

+0

@ElliottFrisch Ich weiß über Umask. Ich wollte wissen, warum denkst du, dass Umask etwas mit der Erstellung von Samba-Dateien zu tun hat und ob es irgendwelche Dokumente gab, auf die du dich beziehst. – recognosco

Antwort

62

Konnte endlich herausfinden, warum die Erlaubnis sich änderte. Die Verwirrung entstand aus der map archive = yes Einstellung, die der Standardwert in Samba ist. Nach dem Setzen von map archive = no hat sich das Owner-Execute-Bit so verhalten, wie ich es erwartet hatte.

Gefunden die Antwort durch Lesen der Dokumentation hier: http://www.samba.org/samba/docs/using_samba/ch08.html in den Dateiberechtigungen und Attribute unter MS-DOS und Unix Abschnitt. Es erwähnt klar diesen Nebeneffekt:

Folglich gibt es keine Verwendung für irgendwelche der drei ausführbaren Unix-Bits, die in einer Datei in einer Samba-Festplattenfreigabe vorhanden sind. DOS-Dateien haben jedoch ihre eigenen Attribute, die beibehalten werden müssen, wenn sie in einer Unix-Umgebung gespeichert werden: das Archiv, das System und verborgene Bits. Samba kann diese Bits erhalten, indem es die ausführbaren Berechtigungsbits der Datei auf der Unix-Seite wiederverwendet - wenn es dazu aufgefordert wird. Das Mapping dieser Bits hat jedoch einen unglücklichen Nebeneffekt: Wenn ein Windows-Benutzer eine Datei in einer Samba-Freigabe speichert und sie unter Unix mit dem Befehl ls -al anzeigt, bedeuten einige der ausführbaren Bits nicht, was Sie erwarten würden zu.

Es ist jedoch auch erwähnt dies:

Wir sollten Sie warnen, dass der Standardwert der Option map archiveyes ist, während die beiden anderen Optionen einen Standardwert von no haben. Dies liegt daran, dass viele Programme nicht ordnungsgemäß funktionieren, wenn das Archivbit für DOS- und Windows-Dateien nicht korrekt gespeichert wird. Das System und verborgene Attribute sind jedoch für die Ausführung eines Programms nicht kritisch und liegen im Ermessen des Administrators.

Sie können auch mehr über das Archiv-Bit hier lesen: http://en.wikipedia.org/wiki/Archive_bit

+1

WOW, tolle Arbeit! –

+2

Danke für die Weiterverfolgung; Ich hatte heute das selbe Problem und diese Antwort rettete den Tag! – carej

+2

Hah, ich habe hier das * genaue * gleiche Problem (git diff zeigt mir 644-755 Berechtigungen ändern), danke dafür –