Back to the main page.
Bug 360 - fix the umask problem with the public peerslaves
| Status | CLOSED INVALID |
| Reported | 2011-01-05 14:03:00 +0100 |
| Modified | 2011-02-23 13:51:09 +0100 |
| Product: | FieldTrip |
| Component: | peer |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P1 normal |
| Assigned to: | Simon Oosthoek |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-01-05 14:03:27 +0100
Simon Oosthoek - 2011-01-12 10:22:31 +0100
Dit is de input die ik van Marcel Zwiers kreeg: Hoi Simon, Ik heb inmiddels ontdekt dat het aan de matlab-shell ligt. Ik krijg nml de gewenste directory als ik een directory het volgende doe: su public [public] umask 0000 mkdir test_su Maar niet als ik in Matlab ditzelfde via p2p doe mbv van de matlab-functie 'mkdir': >> >>peercellfun('mkdir',{'test_matlab'}) Maar als ik in Matlab ditzelfde via p2p doe mbv van een directe unix-call naar 'mkdir' gaat het wel goed: >> >>peercellfun('unix',{'mkdir test_unix'}) Blijft maf dat Matlab de environment verandert, maar hiermee kan ik leven. Groet, Marcel. Voor zover ik weet starten de peerslaves op met een umask 0000 (umask -S a=rwx), zodat alle matlabs door peerslave opgestart ook die umask zouden moeten hebben. Als dat niet zo is, doet matlab wat raars met de umask of vraag matlab niet standaard rw-rw-rw- voor files en rwxrwxrwx voor directories, wat normale processen wel doen. Het umask is alleen een filter, niet een ondergrens. Om te zorgen dat files gecreeerd door peerslaves te verwijderen zijn door de eigenaar van de peermaster zou je bij elke job een chmod -R a+rwX kunnen doen op de directories (en files erin) die aangemaakt zijn door peerslaves.
Simon Oosthoek - 2011-02-09 14:21:07 +0100
problem appears to be possible to live with.