OSX Server 10.2.7, DropBox, transfert de propriete ?

laurent.pertois

05/01/2004 à 23:59

J.P. Poindessault wrote:

J'ai lu ce qui avait été écrit sur le "sticky bit", mais n'ai pas osé tester.

Non, par contre, quand tu définis ton partage, dans la section
Protocoles, Réglages de fichiers Windows, tu as bien :

Autorisations par défaut pour les nouveaux fichiers et dossiers :

Affecter comme suit :
possesseur ce que tu veux
groupe ce que tu veux
Tous ce que tu veux

Sinon, essaie avec ça.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Nicolas.MICHEL

06/01/2004 à 13:48

J.P. Poindessault wrote:

c'est à dire que chaque
utilisateur "user":
- est dans un GROUPE

Comme dans Jaguar, staff ou comme avec Panther, "username" ?
Tu utilises ce groupe ?
ça ne me regarde pas, mais ne vaudrait-il pas mieux baser les
permissions de share sur le groupe plutôt que sur le possesseur ?
En général, il me semble plus sage de baser une structure sur des
ensemble plutôt que sur chaque particulier...

- dépose un DOSSIER (par Drag&drop ou COPIE): le POSSESSEUR de
user_DropOnly peut copier les fichiers ou le dossier vers un autre dossier
lui appartenant MAIS ne peut RIEN EFFACER

Normal.

Pour l'instant, j'ai résolu la question avec un cron genre
15,45 * * * * /usr/local/bin/nmperm
où nmperm est un miniscript genre :

#!/bin/sh
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
HOME=/var/log
chflags -R nouchg /Users/"username"/user_DropOnly
chflags -R nouchg /Users/"username"/user_ReadOnly
chmod -R u+rwX /Users/"username"/user_DropOnly
chmod -R u+rwX /Users/"username"/user_ReadOnly
chown -R "username" /Users/"username"/user_DropOnly
chown -R "username" /Users/"username"/user_ReadOnly

(pour résumer le script s'exécute toutes les heures aux 15 et aux 45. Il
dévérouille, donne accès au proprio puis attribues le fichier au proprio
pour les 2 dossiers user_DropOnly et user_ReadOnly)

Si tu as une kirielle de users, un script qui en extrait la liste et qui
fait ça pour chaque sera nécessaire. Là où j'ai mis ça en place, j'ai
qu'un seul groupe (un seul dossier) donc c'est assez léger. Mes
utilisateurs n'ont rien de si confidentiel qu'ils ne puisse partager
leur données entre eux, et ça reste en interne.

Note qu'il faut avoir une idée assez précise du temps que peut prendre
ce script et ne pas le lancer à une cadence plus rapide qu'il ne dure.
Tu pourais inclure dans ce script la vérif qu'il ne tourne pas déjà.
Sinon, c'est un truc pour que ton serveur parte en caraffe.

Le POSSESSEUR effectif du dossier demeure "l'autre", "l'expéditeur".

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

Comment transférer la propriété au "destinataire" du dossier ?

chown, qui ne marche sauf erreur pas sur un fichier vérouillé

J'ai lu ce qui avait été écrit sur le "sticky bit", mais n'ai pas osé tester.

Avant:
- j'aimerai savoir si ce problème est un défaut connu de OSX Server
10.2.7. ou si j'ai mal paramétré quelque chose

Ce qui résouds ce genre de chose, c'est des ACL (access control list),
mais il n'y en a pas encore sur OSX à ma connaissance.

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

J.P. Poindessault <Jean.Pierre.Poindessault@univ-poitiers.fr> wrote:

c'est à dire que chaque
utilisateur "user":
- est dans un GROUPE

Comme dans Jaguar, staff ou comme avec Panther, "username" ?
Tu utilises ce groupe ?
ça ne me regarde pas, mais ne vaudrait-il pas mieux baser les
permissions de share sur le groupe plutôt que sur le possesseur ?
En général, il me semble plus sage de baser une structure sur des
ensemble plutôt que sur chaque particulier...

- dépose un DOSSIER (par Drag&drop ou COPIE): le POSSESSEUR de
user_DropOnly peut copier les fichiers ou le dossier vers un autre dossier
lui appartenant MAIS ne peut RIEN EFFACER

Normal.

Pour l'instant, j'ai résolu la question avec un cron genre
15,45 * * * * /usr/local/bin/nmperm
où nmperm est un miniscript genre :

#!/bin/sh
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
HOME=/var/log
chflags -R nouchg /Users/"username"/user_DropOnly
chflags -R nouchg /Users/"username"/user_ReadOnly
chmod -R u+rwX /Users/"username"/user_DropOnly
chmod -R u+rwX /Users/"username"/user_ReadOnly
chown -R "username" /Users/"username"/user_DropOnly
chown -R "username" /Users/"username"/user_ReadOnly

(pour résumer le script s'exécute toutes les heures aux 15 et aux 45. Il
dévérouille, donne accès au proprio puis attribues le fichier au proprio
pour les 2 dossiers user_DropOnly et user_ReadOnly)

Si tu as une kirielle de users, un script qui en extrait la liste et qui
fait ça pour chaque sera nécessaire. Là où j'ai mis ça en place, j'ai
qu'un seul groupe (un seul dossier) donc c'est assez léger. Mes
utilisateurs n'ont rien de si confidentiel qu'ils ne puisse partager
leur données entre eux, et ça reste en interne.

Note qu'il faut avoir une idée assez précise du temps que peut prendre
ce script et ne pas le lancer à une cadence plus rapide qu'il ne dure.
Tu pourais inclure dans ce script la vérif qu'il ne tourne pas déjà.
Sinon, c'est un truc pour que ton serveur parte en caraffe.

Le POSSESSEUR effectif du dossier demeure "l'autre", "l'expéditeur".

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

Comment transférer la propriété au "destinataire" du dossier ?

chown, qui ne marche sauf erreur pas sur un fichier vérouillé

J'ai lu ce qui avait été écrit sur le "sticky bit", mais n'ai pas osé tester.

Avant:
- j'aimerai savoir si ce problème est un défaut connu de OSX Server
10.2.7. ou si j'ai mal paramétré quelque chose

Ce qui résouds ce genre de chose, c'est des ACL (access control list),
mais il n'y en a pas encore sur OSX à ma connaissance.

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Vous avez filtré cet utilisateur ! Consultez son message

J.P. Poindessault wrote:

c'est à dire que chaque
utilisateur "user":
- est dans un GROUPE

Comme dans Jaguar, staff ou comme avec Panther, "username" ?
Tu utilises ce groupe ?
ça ne me regarde pas, mais ne vaudrait-il pas mieux baser les
permissions de share sur le groupe plutôt que sur le possesseur ?
En général, il me semble plus sage de baser une structure sur des
ensemble plutôt que sur chaque particulier...

- dépose un DOSSIER (par Drag&drop ou COPIE): le POSSESSEUR de
user_DropOnly peut copier les fichiers ou le dossier vers un autre dossier
lui appartenant MAIS ne peut RIEN EFFACER

Normal.

Pour l'instant, j'ai résolu la question avec un cron genre
15,45 * * * * /usr/local/bin/nmperm
où nmperm est un miniscript genre :

#!/bin/sh
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
HOME=/var/log
chflags -R nouchg /Users/"username"/user_DropOnly
chflags -R nouchg /Users/"username"/user_ReadOnly
chmod -R u+rwX /Users/"username"/user_DropOnly
chmod -R u+rwX /Users/"username"/user_ReadOnly
chown -R "username" /Users/"username"/user_DropOnly
chown -R "username" /Users/"username"/user_ReadOnly

(pour résumer le script s'exécute toutes les heures aux 15 et aux 45. Il
dévérouille, donne accès au proprio puis attribues le fichier au proprio
pour les 2 dossiers user_DropOnly et user_ReadOnly)

Si tu as une kirielle de users, un script qui en extrait la liste et qui
fait ça pour chaque sera nécessaire. Là où j'ai mis ça en place, j'ai
qu'un seul groupe (un seul dossier) donc c'est assez léger. Mes
utilisateurs n'ont rien de si confidentiel qu'ils ne puisse partager
leur données entre eux, et ça reste en interne.

Note qu'il faut avoir une idée assez précise du temps que peut prendre
ce script et ne pas le lancer à une cadence plus rapide qu'il ne dure.
Tu pourais inclure dans ce script la vérif qu'il ne tourne pas déjà.
Sinon, c'est un truc pour que ton serveur parte en caraffe.

Le POSSESSEUR effectif du dossier demeure "l'autre", "l'expéditeur".

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

Comment transférer la propriété au "destinataire" du dossier ?

chown, qui ne marche sauf erreur pas sur un fichier vérouillé

J'ai lu ce qui avait été écrit sur le "sticky bit", mais n'ai pas osé tester.

Avant:
- j'aimerai savoir si ce problème est un défaut connu de OSX Server
10.2.7. ou si j'ai mal paramétré quelque chose

Ce qui résouds ce genre de chose, c'est des ACL (access control list),
mais il n'y en a pas encore sur OSX à ma connaissance.

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas.MICHEL

06/01/2004 à 14:31

Nicolas MICHEL wrote:

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

J'étais justement en train de lire le man de smb.conf, et j'y ai trouvé
ceci :
profile acls (S)
This boolean parameter controls whether smbd(8) This boolean
parameter was added to fix the problems that people have been
having with storing user profiles on Samba shares from Windows
2000 or Windows XP clients. New versions of Windows 2000 or Win-
dows XP service packs do security ACL checking on the owner and
ability to write of the profile directory stored on a local
workstation when copied from a Samba share.

When not in domain mode with winbindd then the security info
copied onto the local workstation has no meaning to the logged
in user (SID) on that workstation so the profile storing fails.
Adding this parameter onto a share used for profile storage
changes two things about the returned Windows ACL. Firstly it
changes the owner and group owner of all reported files and
directories to be BUILTINAdministrators, BUILTINUsers
respectively (SIDs S-1-5-32-544, S-1-5-32-545). Secondly it adds
an ACE entry of "Full Control" to the SID BUILTINUsers to
every returned ACL. This will allow any Windows 2000 or XP work-
station user to access the profile.

Note that if you have multiple users logging on to a workstation
then in order to prevent them from being able to access each
others profiles you must remove the "Bypass traverse checking"
advanced user right. This will prevent access to other users
profile directories as the top level profile directory (named
after the user) is created by the workstation profile code and
has an ACL restricting entry to the directory tree to the owning
user.

Default: profile acls = no

je suis pas sûr que ça fasse ce que tu veux, et si oui ça ne le fera
qu'en smb bien-sûr, mais si tu y parviens, merci de nous le poster :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

J'étais justement en train de lire le man de smb.conf, et j'y ai trouvé
ceci :
profile acls (S)
This boolean parameter controls whether smbd(8) This boolean
parameter was added to fix the problems that people have been
having with storing user profiles on Samba shares from Windows
2000 or Windows XP clients. New versions of Windows 2000 or Win-
dows XP service packs do security ACL checking on the owner and
ability to write of the profile directory stored on a local
workstation when copied from a Samba share.

When not in domain mode with winbindd then the security info
copied onto the local workstation has no meaning to the logged
in user (SID) on that workstation so the profile storing fails.
Adding this parameter onto a share used for profile storage
changes two things about the returned Windows ACL. Firstly it
changes the owner and group owner of all reported files and
directories to be BUILTIN\Administrators, BUILTIN\Users
respectively (SIDs S-1-5-32-544, S-1-5-32-545). Secondly it adds
an ACE entry of "Full Control" to the SID BUILTIN\Users to
every returned ACL. This will allow any Windows 2000 or XP work-
station user to access the profile.

Note that if you have multiple users logging on to a workstation
then in order to prevent them from being able to access each
others profiles you must remove the "Bypass traverse checking"
advanced user right. This will prevent access to other users
profile directories as the top level profile directory (named
after the user) is created by the workstation profile code and
has an ACL restricting entry to the directory tree to the owning
user.

Default: profile acls = no

je suis pas sûr que ça fasse ce que tu veux, et si oui ça ne le fera
qu'en smb bien-sûr, mais si tu y parviens, merci de nous le poster :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Vous avez filtré cet utilisateur ! Consultez son message

Nicolas MICHEL wrote:

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

J'étais justement en train de lire le man de smb.conf, et j'y ai trouvé
ceci :
profile acls (S)
This boolean parameter controls whether smbd(8) This boolean
parameter was added to fix the problems that people have been
having with storing user profiles on Samba shares from Windows
2000 or Windows XP clients. New versions of Windows 2000 or Win-
dows XP service packs do security ACL checking on the owner and
ability to write of the profile directory stored on a local
workstation when copied from a Samba share.

When not in domain mode with winbindd then the security info
copied onto the local workstation has no meaning to the logged
in user (SID) on that workstation so the profile storing fails.
Adding this parameter onto a share used for profile storage
changes two things about the returned Windows ACL. Firstly it
changes the owner and group owner of all reported files and
directories to be BUILTINAdministrators, BUILTINUsers
respectively (SIDs S-1-5-32-544, S-1-5-32-545). Secondly it adds
an ACE entry of "Full Control" to the SID BUILTINUsers to
every returned ACL. This will allow any Windows 2000 or XP work-
station user to access the profile.

Note that if you have multiple users logging on to a workstation
then in order to prevent them from being able to access each
others profiles you must remove the "Bypass traverse checking"
advanced user right. This will prevent access to other users
profile directories as the top level profile directory (named
after the user) is created by the workstation profile code and
has an ACL restricting entry to the directory tree to the owning
user.

Default: profile acls = no

je suis pas sûr que ça fasse ce que tu veux, et si oui ça ne le fera
qu'en smb bien-sûr, mais si tu y parviens, merci de nous le poster :)

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Jean.Pierre.Poindessault

06/01/2004 à 19:19

In article <1g74539.13is2eieyv964N%,
(Laurent Pertois) wrote:

J.P. Poindessault wrote:

J'ai lu ce qui avait été écrit sur le "sticky bit", mais n'ai pas osé
tester.

Non, par contre, quand tu définis ton partage, dans la section
Protocoles, Réglages de fichiers Windows, tu as bien :

Autorisations par défaut pour les nouveaux fichiers et dossiers :

Affecter comme suit :
possesseur ce que tu veux
groupe ce que tu veux
Tous ce que tu veux

Sinon, essaie avec ça.
-------

1- Avant:
mon dossier JPP est un sharepoint
JPP contient jpp_DropOnly qui N'EST PAS un share point (les
paramètres "protocole" sont grisés),
Si james dépose un fichier dans jppDropOnly, jpp peut l'effacer
Si james dépose un dossier dans jppDropOnly, jpp ne peut pas l'effacer

1- Après:
mon dossier JPP est un sharepoint
JPP contient jpp_DropOnly qui EST un share point. Je définit
les droits:
owner: Read&Write
group: Write Only
everyone: Write Only
Si james dépose un fichier dans jppDropOnly, jpp peut l'effacer
Si james dépose un dossier dans jppDropOnly, jpp ne peut pas l'effacer

Il n'y a donc rien de changé.

JPP

Jean.Pierre.Poindessault

06/01/2004 à 19:28

In article <1g756gc.gp4tbf1vn3wxyN%,
(Nicolas MICHEL) wrote:

J.P. Poindessault wrote:

c'est à dire que chaque
utilisateur "user":
- est dans un GROUPE

Comme dans Jaguar, staff ou comme avec Panther, "username" ?
------

Staff, je suis en 10.2.7
------

Tu utilises ce groupe ?
-----

quel groupe ? "staff" semble être le groupe de tous les utilisatateurs
déclarés dans Netinfo.
-----

ça ne me regarde pas, mais ne vaudrait-il pas mieux baser les
permissions de share sur le groupe plutôt que sur le possesseur ?
En général, il me semble plus sage de baser une structure sur des
ensemble plutôt que sur chaque particulier...
-----

Cela m'est difficile car nous souhaitons vraiment distinguer pour chaque
individu:
1- son espace PERSO
2- un espace où il met des documents à la disposition des "autres" (staff)
3- un espace où il reçoit les documents des "autres" (staff)
pour -2- staff est en Read only
pour -3- staff est en Write only
-------

- dépose un DOSSIER (par Drag&drop ou COPIE): le POSSESSEUR de
user_DropOnly peut copier les fichiers ou le dossier vers un autre dossier
lui appartenant MAIS ne peut RIEN EFFACER

Normal.
-----

Pourquoi ?
Ce qui me choque et me perturbe est que l'effacement est possible pour un
FICHIER et pas pour un DOSSIER.
D'après ce que j'ai lu, ce serait une histoire de "sticky bit" mais je
voudrais bien savoir comment fixer ce foutu bit de façon définitive sur mes
user_Drop_Only !

Merci de ta contribution.

JPP

Jean.Pierre.Poindessault

06/01/2004 à 19:37

In article <1g759k8.1kttl0s6ae912N%,
(Nicolas MICHEL) wrote:

Nicolas MICHEL wrote:

Sauf si tu spécifies dans le réglage du share une certaine option que
j'ai plus en tête pour l'appletalk, et qui fait un truc genre "ignorer
les permissions". Pour le partage smb, je ne sais pas si c'est possible.
man smb.conf...

J'étais justement en train de lire le man de smb.conf, et j'y ai trouvé
ceci :
-------

Merci Nicolas. Je mets ça sous le coude et vais regarder à tête reposée.
J'ai trouvé:
http://www.osxfaq.com/man/8/sticky.ws
et ceci dans une autre page:
--------
If mode ISVTX (the `sticky bit') is set on a directory, an unprivileged
user may not delete or rename files of other users in that directory. The
sticky bit may be set by any user on a directory which the user owns or
has appropriate permissions. For more details of the properties of the
sticky bit, see sticky(8).
--------
C'et ce que modifie ton script si j'ai bien compris.
Mais pourquoi n'est-ce pas permanet sur le CONTENU du dossier ???
ce qui justifie le CRON que tu écris.

JPP

laurent.pertois

06/01/2004 à 19:41

J.P. Poindessault wrote:

D'après ce que j'ai lu, ce serait une histoire de "sticky bit" mais je
voudrais bien savoir comment fixer ce foutu bit de façon définitive sur mes
user_Drop_Only !

Le sticky bit permet de protéger un fichier en autorisant un utilisateur
à le modifier mais en ne permettant l'effacement que par le possesseur
ou le possesseur du dossier (et root, bien entendu).

Pour le placer, soit tu dégaines le Terminal et tu rajoutes un 1 devant
les droits attribués, par exemple pour un dossier :

Possesseur : rwx
Groupe : -wx
Tous : ---

chmod 1730 /chemin/vers/ton_dossier

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

laurent.pertois

06/01/2004 à 19:46

J.P. Poindessault wrote:

C'et ce que modifie ton script si j'ai bien compris.

Non, son script dévérouille les fichiers présents dans les dossiers et
les remets en lecture/écriture/exécution pour tout le monde.

Mais pourquoi n'est-ce pas permanet sur le CONTENU du dossier ???
ce qui justifie le CRON que tu écris.

Ben, vu qu'il traite tous les fichiers un par un régulièrement, ça ne
s'applique pas au dossier.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Nicolas.MICHEL

07/01/2004 à 10:36

J.P. Poindessault wrote:

In article <1g756gc.gp4tbf1vn3wxyN%,
(Nicolas MICHEL) wrote:

Tu utilises ce groupe ?
-----

quel groupe ? "staff" semble être le groupe de tous les utilisatateurs
déclarés dans Netinfo.

Par défaut, c'est le cas. Mais rien ne t'empêche de modifier celà.
C'est une question politique, et non informatique, et qui ne me ragarde
pas, comme je l'ai dit. Mais souvent, à ne rien vouloir partager on est
dans la M* quand la personne est absente. Raison pour laquelle ici
j'organise tout en groupes : Le groupe compta, le groupe IT, ... On part
du principe qu'au sein du même groupe, la confiance règne. Celà implique
bien sûr la création de groupes spécifiques. En outres, celà diminue
significativement le nombre de dossiers partagés et donc le travail de
maintennance.

Normal.
-----

Pourquoi ?

Parce que la sécurité s'applique à chaque fichier, pas seulement aux
dossiers partagés, comme c'est le cas sous OS9.

Ce qui me choque et me perturbe est que l'effacement est possible pour un
FICHIER et pas pour un DOSSIER.

Si, je suppose que celà s'applique aussi aux dossiers. Mais pas aux
éléments inclus dans lesdit dossiers. S'il est vide, tu devrais pouvoir
le jetter sans problèmes.

D'après ce que j'ai lu, ce serait une histoire de "sticky bit" mais je
voudrais bien savoir comment fixer ce foutu bit de façon définitive sur mes
user_Drop_Only !

non, le "sticky bit" n'agit pas dans les sous-dossiers.
Mon script ne touche pas dureste à ce "sticky bit", il fait 3 choses :
il dévérouille, il donne accès au possesseur et il change le possesseur.
Note qu'il le fait récursivement dans les sous-dossiers :)
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Jean.Pierre.Poindessault

07/01/2004 à 12:05

In article <1g76sdu.oz2zq51kw1zbmN%,
(Nicolas MICHEL) wrote:

Normal.
-----

Pourquoi ?

Parce que la sécurité s'applique à chaque fichier, pas seulement aux
dossiers partagés, comme c'est le cas sous OS9.

Ce qui me choque et me perturbe est que l'effacement est possible pour un
FICHIER et pas pour un DOSSIER.

Si, je suppose que celà s'applique aussi aux dossiers. Mais pas aux
éléments inclus dans lesdit dossiers. S'il est vide, tu devrais pouvoir
le jetter sans problèmes.
----------

Je reprends, en faisant référence aux copies d'écran que je t'ai envoyées:
1- si dans jpp_DropOnly, james dépose le fichier 01.psd: jpp peut l'effacer
ALORS que james est toujours propriétaire et que "staff" et "others" ne
sont que ReadOnly

2- si james dépose le dossier PanSuccero, jpp ne peut pas l'effacer alors
que la fenêtre d'info donne strictement les mêmes droits que l'info sur le
FICHIER

Il semble donc que le dépôt d'un fichier (via Windows, je ne suis pas sûr
avec OSX ou OS9, je vais tester) est associé à un transfert de propriété
vers le destinataire, SANS le montrer dans INFO, alors que pour un dossier,
les droits initiaux sont conservés, sans transfert de propriété.

Et là est tout mon problème !!!

Merci de ta contribution

JPP

OSX Server 10.2.7, DropBox, transfert de propriete ?

10 réponses

Veuillez sélectionner un problème