Novell Client und ATTRIB

[Olaf Erkens]

Tach Noveller,

gegeben NW65 und ein Batchjob unter Win7/32bit, der bis Novell Client 2
SP3 für Windows 7 (IR3) bestens funktionierte. Nun Novell Client 2 SP3
für Windows 7 (IR5) installiert und schon knallt es beim zweiten Aufruf.
Unter WinXP mit aktuellem Novell Client passiert der Fehler nicht.

Im Batchjob werden Attribute gesetzt:

ATTRIB -R *.* /S
COPY ...
ATTRIB +R *.* /S

Beim zweiten Aufruf unter neuem Client produziert das COPY ein "Zugriff
verweigert". Das erneute ATTRIB -R entfernt zwar das "Read-only", aber
nicht das ebenfalls gesetzte "Delete Inhibit" ... was unter alten
Clientversion und unter WinXP klappt.

Ein "ndir *.* /di /sub" behauptet unter Win7, es seinen keine Dateien
mit "delete inhibt" vorhanden ... WinXP wie erwartet findet sehr wohl
welche.

Irgendwelche Hinweise zur Lösung?

Kommentare der Art "Upgrade auf OES11" sind über ... komm ich erst im
Laufe des Jahres zu - wenn überhaupt.

Viele Grüße

Olaf

[Massimo Rosen]

Caching *auf dem client* abgeschaltet? Windows 7 clients kümmern sich
nicht um die Netware set parameter und cachen wenn lokal erlaubt trotzdem.

CU,
Massimo

[Olaf Erkens]

Am 2014-02-12 19:06, schrieb Massimo Rosen:

>> Beim zweiten Aufruf unter neuem Client produziert das COPY ein "Zugriff
>> verweigert". Das erneute ATTRIB -R entfernt zwar das "Read-only", aber
>> nicht das ebenfalls gesetzte "Delete Inhibit" ... was unter alten
>> Clientversion und unter WinXP klappt.
>

> Caching *auf dem client* abgeschaltet? Windows 7 clients kümmern sich
> nicht um die Netware set parameter und cachen wenn lokal erlaubt trotzdem.

Du meinst *im* Netware Client? Datei-Caching steht dort (schon lange)
auf "aus", Datei-Commit auf "ein". Oder meintest du was anderes?

Viele Grüße

Olaf

[Jens Wilke]

Massimo Rosen schrieb:

> On 12.02.2014 15:37, Olaf Erkens wrote:

[...]

> > ATTRIB -R *.* /S
> > COPY ...
> > ATTRIB +R *.* /S

[...]

> Caching *auf dem client* abgeschaltet? Windows 7 clients kümmern sich
> nicht um die Netware set parameter und cachen wenn lokal erlaubt trotzdem.

ich drösel nach einigen Tests mit 32bit Win7SP1 und Client 2SP3 IR2
bis IR5 mal etwas auf.

ATTRIB +R setzt bis 2.0SP3-IR4 folgende Attribute:

Win: "Schreibgeschützt"
Netware: "Nur Lesen" + "Löschen gesperrt"
"Umbenennen gesperrt" + "Löschen gesperrt" werden ausgegraut.

ATTRIB -R löscht alle Attribute wieder.
ATTRIb -R löscht auch das DI, wenn es als einziges gesetzt ist

wunderbar.

Ab SP3-IR5 setzt ATTRIB +R immernoch die oben genannten Attribute.
ATTRIB -R löscht aber nicht mehr das Delete Inhibit!

Ich habe hier auch einige kompilierte AUTOIT-Skripte, die (plötzlich)
nicht mehr direkt zB NIPP-S.EXE per RunWait(), bzw. Run() auf einem
Netzwerklaufwerk (per UNC-Pfad) aufrufen können, es kommt keine
UAC-Abfrage mehr.
Rufe ich eine Batch auf, die dann NIPP-S.EXE aufruft, klappt es.

PS: Folgendes wird hier standardmäßig gesetzt:

[NovellClientParameters]
!Computer_Only_Logon_Default=Never
!Computer_Only_Logon_Default_Distribute=Always
!Show_Forgotten_Password_Prompt=NO
!Show_Forgotten_Password_Prompt_Distribute=Always
!File_Commit=ON
!File_Commit_Distribute=Always
!AutoAdminQueryNDS=YES
!AutoAdminQueryNDS_Distribute=Always
!File_Caching=OFF
!File_Caching_Distribute=Always

Bis denne

Jens

[Jens Wilke]

Auch über den Kontext im Explorer geschieht dasselbe im IR5.
Wenn ich RO setze, muss ich, um es wieder loszuwerden, erst RO wieder
abwählen und danach zusätzlich noch DI abwählen.

Der IR5 ist aber recht wichtig, weil ich vorher zB beim Entpacken von
RAR/ZIPs im Netz das Problem hatte, die Verzeichniserstellung nicht
richtig funktionierte -> Verzeichnis wurde erstellt, trotzdem kam eine
Fehlermeldung und man musste für *jedes* integrierte Verzeichnis das
unzippen neu starten, bis alle Verzeichnisse vorhanden waren.

BTW:

https://forums.novell.com/showthread.php/474102-Delete-inhibit-gets-set-when-trying-to-delete-RO-files-with-Client2-SP3-IR5

Bei uns besteht das Problem erst seit IR5.

Bis denne

Jens

[Olaf Erkens]

Am 2014-02-12 19:06, schrieb Massimo Rosen:

>> Beim zweiten Aufruf unter neuem Client produziert das COPY ein "Zugriff
>> verweigert". Das erneute ATTRIB -R entfernt zwar das "Read-only", aber
>> nicht das ebenfalls gesetzte "Delete Inhibit" ... was unter alten
>> Clientversion und unter WinXP klappt.

Irgendwelche Lösungen in Sicht? Wir haben gerade auch den Novell Client
2 SP3 für Windows 7 (IR6) probiert - gleiches Problem.

Viele Grüße

Olaf

P.S. Dafür funktioniert seit IR5 jetzt endlich das Autoadminlogin
einwandfrei ... immerhin etwas erfreuliches.

[Massimo Rosen]

On 28.02.2014 13:21, Olaf Erkens wrote:
> Am 2014-02-12 19:06, schrieb Massimo Rosen:
>
>>> Beim zweiten Aufruf unter neuem Client produziert das COPY ein "Zugriff
>>> verweigert". Das erneute ATTRIB -R entfernt zwar das "Read-only", aber
>>> nicht das ebenfalls gesetzte "Delete Inhibit" ... was unter alten
>>> Clientversion und unter WinXP klappt.
>
> Irgendwelche Lösungen in Sicht? Wir haben gerade auch den Novell Client
> 2 SP3 für Windows 7 (IR6) probiert - gleiches Problem.

Ich hab's gemeldet und es ist ein Bug.

*Aber*: Das Problem gibt es nur bei Netware Servern. Denn das setzen von
DI kommt vom Server, nicht vom Client. Ein OES/Linux Server setzt
nämlich beim "Attrib +R" DI eben *nicht*.

Das nur zur Erklärung warum....

CU,
Massimo

[Olaf Erkens]

Hallo Massimo

>> Irgendwelche Lösungen in Sicht? Wir haben gerade auch den Novell Client
>> 2 SP3 für Windows 7 (IR6) probiert - gleiches Problem.
>
> Ich hab's gemeldet und es ist ein Bug.

Danke

> *Aber*: Das Problem gibt es nur bei Netware Servern. Denn das setzen von
> DI kommt vom Server, nicht vom Client. Ein OES/Linux Server setzt
> nämlich beim "Attrib +R" DI eben *nicht*.

Leider können wir derzeit nicht "tief fliegen" und auf die Schnelle auf
OES11 umstellen.

> Das nur zur Erklärung warum....

Ich hab mir fast schon sowas gedacht :-)

Viele Grüße

Olaf

[Christoph Maercker]

Jens Wilke wrote:
> Der IR5 ist aber recht wichtig, weil ich vorher zB beim Entpacken von
> RAR/ZIPs im Netz das Problem hatte, die Verzeichniserstellung nicht
> richtig funktionierte -> Verzeichnis wurde erstellt, trotzdem kam eine
> Fehlermeldung und man musste für *jedes* integrierte Verzeichnis das
> unzippen neu starten, bis alle Verzeichnisse vorhanden waren.

Ich nutze noch Novell Client 2 SP1 für Windows 7. Mit dem habe ich das
Problem, dass ZIP-Archive, die ich auf einem gemapptes
NetWare(5)-Laufwerk packe, mit Fehlermeldung quittiert und gelöscht
werden! Beim Entpacken gibt es keine Probleme.

--


CU Chr. Maercker.

[Jens Wilke]

Christoph Maercker schrieb:

Wenn du das auch mit dem internen Windows-Zipper machst ;-) ...den
habe ich nie benutzt.
Wobei...ich erinnere mich ganz ganz dunkel an ähnliche Probleme.

Bis denne

Jens

[Christoph Maercker]

Jens Wilke wrote:
> Wenn du das auch mit dem internen Windows-Zipper machst ;-) ...den
> habe ich nie benutzt.

Nicht ganz: ich benutze Total Commander. Ob der zum Zippen Win-APIs
nutzt, müsste ich nachfragen.

> Wobei...ich erinnere mich ganz ganz dunkel an ähnliche Probleme.

Ich teste mal, ob sich 7ZIP bzw. PowerArc anders verhalten.
--


CU Chr. Maercker.

[Christoph Maercker]

Jens Wilke wrote:
> Wenn du das auch mit dem internen Windows-Zipper machst ;-) ...den
> habe ich nie benutzt.

Total Commander nutzt offenbar wirklich die gleichen Windoof-APIs wie
Äksplorer. Mit PowerArc lassen sich auf dem gleichen NetWare-Laufwerk
problemlos Archive anlegen und aktualisieren.
--


CU Chr. Maercker.

[sven.g...@gmail.com]

Am Freitag, 28. Februar 2014 17:14:14 UTC+1 schrieb Massimo Rosen:
> *Aber*: Das Problem gibt es nur bei Netware Servern. Denn das setzen von
> DI kommt vom Server, nicht vom Client. Ein OES/Linux Server setzt
> nämlich beim "Attrib +R" DI eben *nicht*.

Trotzdem: mit einem 4.91er Client tritt das Problem nicht auf - mit diesem wird das Di ordentlich wieder mit gelöscht, und das Ri gleich mit. Warum soll sich also der NWClient2 anders verhalten - nur um die Netware-Server dieser Welt auch wirklich zum Ende zu zwingen?
(das wären doch eher M$-Methoden...)

[Massimo Rosen]

On 21.05.2014 12:35, sven.g...@gmail.com wrote:
> Am Freitag, 28. Februar 2014 17:14:14 UTC+1 schrieb Massimo Rosen:
>> *Aber*: Das Problem gibt es nur bei Netware Servern. Denn das setzen von
>> DI kommt vom Server, nicht vom Client. Ein OES/Linux Server setzt

>> n�mlich beim "Attrib +R" DI eben *nicht*.
>
> Trotzdem: mit einem 4.91er Client tritt das Problem nicht auf - mit diesem wird das Di ordentlich wieder mit gel�scht, und das Ri gleich mit. Warum soll sich also der NWClient2 anders verhalten - nur um die Netware-Server dieser Welt auch wirklich zum Ende zu zwingen?
> (das w�ren doch eher M$-Methoden...)
>

Nein, das Problem ist viel komplexer.

Alte Clients hatten eigentlich alle einen uralten Bug, der
Novell-spezifische Attribute (unter anderen DI und RI, aber auch die zum
Thema Kompression zum Beispiel) von Dateien entfernt hat, wenn Windows
Apis irgendein Windows Attribut entfert haben.

Diese Bug hat Novell nun gefixt, und dabei leider diese Problem erzeugt.
Ich muss zugeben, auch ich hatte keine Ahnung dass das Setzen von DI
wenn man am Client eine Datei auf Read Only setzt vom (Netware) Server
kommt, und eben nicht vom Client. Der Sinn dahinter erschlie�t sich mir
nicht, und auch das VErhalten ist vermutlich ein uralter Workaround f�r
irgendwas. Jedenfalls macht OES/Linux das eben nicht. Also gibt es da
auch kein Problem, und da funktonieren die Attribute DI und RI endlich,
nach tats�chlich Jahrzehnten, so wie sie es sollen.

Denn *eigentlich* ist es nicht Sinn der Sache, dass das Entfernen des
Windows Attributs "RO" gleichzeitig auch das *zus�tzliche* Novell
Attribut RI oder/und DI mit entfernt. Genau wie es eben auch nicht
sinnvoll ist, dass eins der zus�tzlichen Novell Attribute automatisch
mit gesetzt wird wenn RO von Windows kommt. Denn beides macht diese
zus�tzlichen Attribute komplett �berfl�ssig.

CU,
Massimo

[Christoph Maercker]

Jens Wilke wrote:
> Wobei...ich erinnere mich ganz ganz dunkel an �hnliche Probleme.

Mit SP2 des Novell-Clients sind die Probleme verschwunden, die
ZIP-Archive werden nicht mehr zerschossen.
Daf�r muss ich mich nach jedem Ruhezustand neu anmelden und die
NW-Drives neu mappen. :-\
--


CU Chr. Maercker.

[sven.g...@gmail.com]

Für alle die hier noch mitlesen...

Auch wenn es scheinbar ein reines Netware-Problem war, ist es dennoch in IR8 gefixt!

https://www.novell.com/support/kb/doc.php?id=7015328&path=780&number=f.1
https://download.novell.com/Download?buildid=4bBKN2Ek76Q~

[Massimo Rosen]

On 15.07.2014 10:55, sven.g...@gmail.com wrote:
> F�r alle die hier noch mitlesen...

>
> Auch wenn es scheinbar ein reines Netware-Problem war, ist es dennoch in IR8 gefixt!

Ist Definitionssache. Ein bestimmtes Verhalten von Netware in Verbindung
mit dem neuen Fix im Client hat das Problem produziert. Ein OES Server
mit demselben Client hatte das Problem nie, weil sich OES anders verh�lt
als Netware.

Es ist *einigerma�en* logisch das Problem im Client zu "fixen" (wohl
eher, zu umgehen), da Novel Netware codeseitig nur sehr ungerne noch
anfasst.

Die Frage ist jetzt, *wie* haben sie es gefixt? L�scht der Client DI/RI
beim Entfernen von RO jetzt wieder grunds�tzlich immer (und macht DI/RI
damit pauschal erneut nutzlos), oder tut er das nur bei Netware Servern
(da nur die DI/RI automatisch setzen).

M�sste man mal testen..

CU,
Massimo