Is the sky actually falling? (NTFS streams) - some additional notes - part 2

[Guenter Kukkukk]

How well does samba - and *nix itself - handle a _special_ xattr case?
======================================================================

All the following tests have been done on an OS/2 Warp4 box running against
the latest svn revisions of
  - samba3 (rev 11509)
  - samba4 (rev 11509)
both running on SuSE 9.1. The used file system is supporting xattr.
The native linux tests at the bottom have been done on SuSE 9.1.

Using OS/2 tstmaxeas.exe, three files 'file1', 'file2' and 'file3' are
created:
  'file1' is using 1 EA name GK0
  'file2' is using 1 EA name CB0
  'file3' is using 1 EA name MY0

==> Create 'file1':
[<server01>-f:\sh\sambaos2\os2\tstmaxeas]tstmaxeas y:file1 GK 8,1
Used parms: maxeasize=8 maxeanames=1 maxeastart=1 maxeadebug=0
Creating file "y:file1".
openaction: 2 [FILE_CREATED]
Max. EA size for "GK0"=8 [but could be possibly larger]
Total raw EA size: 8
With overhead, should result to a 'displayed' EA size: 20
NOTE: More EAs could be available!

==> Create 'file2' and 'file3':
[<server01>-f:\sh\sambaos2\os2\tstmaxeas]tstmaxeas y:file2 CB 8,1
[<server01>-f:\sh\sambaos2\os2\tstmaxeas]tstmaxeas y:file3 MY 8,1

==> Dump the EAs from file3: (all seem fine so far):
[<server01>-f:\sh\sambaos2\os2\eas]eas y:file3
flags: 0x00 name_length:   3 value_length:     8 name: MY0
0000:  00 00 00 00 04 00 00 00                            ........

==> The EA size (20) is diplayed on the left of the file name.
    So all 3 files now have an EA size of 20:

[<server01>-f:\sh\sambaos2\os2\tstmaxeas]y:
[<server01>-y:\testeasgk]dir
 4.11.05   0.16              14          20  file1
 4.11.05   0.16              14          20  file2
 4.11.05   0.25              14          20  file3

==> Now 'file1' is copied over the _already_ existing 'file3'.
    Btw - on OS/2 and windows, 'file3' would now be a 1:1 duplicate
    of 'file1' (including the EAs):

[<server01>-y:\testeasgk]copy file1 file3

==> A 'dir' cmd shows, that the EA size of 'file3' has increased:

<server01>-y:\testeasgk]dir
 4.11.05   0.16              14          20  file1
 4.11.05   0.16              14          20  file2
 4.11.05   0.16              14          36  file3

==> To make it a bit more clearer, we now copy 'file2' over 'file3':
[<server01>-y:\testeasgk]copy file2 file3

==> The EA size of 'file3' has increased again!:
[<server01>-y:\testeasgk]dir
 4.11.05   0.16              14          20  file1
 4.11.05   0.16              14          20  file2
 4.11.05   0.16              14          52  file3

==> Something seems to be accumulating in 'file3'!
    So we display the EAs of 'file3':

[<server01>-f:\sh\sambaos2\os2\eas]eas y:file3
flags: 0x00 name_length:   3 value_length:     8 name: MY0
0000:  00 00 00 00 04 00 00 00                            ........
flags: 0x00 name_length:   3 value_length:     8 name: GK0
0000:  00 00 00 00 04 00 00 00                            ........
flags: 0x00 name_length:   3 value_length:     8 name: CB0
0000:  00 00 00 00 04 00 00 00                            ........

Conclusion:
===========
The EAs have accumulated in 'file3' - which is not the intended behaviour
when being compared to what OS/2 and windows are doing!
Btw - this does only happen, if _different_ EA names are used!
--------------------------------------------------------------------------

To dig a bit beeper, I did port my tstmaxeas applet over to linux.
And (of course) - my 1st try went the same "accumulation" way.
So, porting that stuff was _not_ very well done by me.

The glitch was, that "opening and truncating an existing file" on OS/2
and windows does not only truncate the former file size - all former
EAs are removed, too!

With linux, the open() function like
  fd = open (fname, O_WRONLY | O_CREAT | O_TRUNC, S_IRWXU);
on an _already existing_ file, which is containing (user) EAs, the file size
is truncated to zero, but all former EAs will remain!

I guess, that's due to the current weak integration of xattr in linux!?

So, I changed my linux applet - and now it's working fine!
(not counting some nasty overhead ...)
--------------------------------------------------------------------------

My next question was "How do the linux core-utils handle this stuff"?
=====================================================================

I might have ignored some available options here (so please, correct me)!
(with 'cp', i know a bit about the '-p' and '--atribute= ' options ...)

linux200:/gkpub/unixeas # touch f1 f2 f3
linux200:/gkpub/unixeas # setfattr -n $'user.GK0' -v $'Some text for GK0' f1
linux200:/gkpub/unixeas # setfattr -n $'user.CB0' -v $'Some text for CB0' f2
linux200:/gkpub/unixeas # setfattr -n $'user.MY0' -v $'Some text for MY0' f3
linux200:/gkpub/unixeas # getfattr -d f3
# file: f3
user.MY0="Some text for MY0"

linux200:/gkpub/unixeas # cp f1 f3
linux200:/gkpub/unixeas # cp f2 f3
linux200:/gkpub/unixeas # getfattr -d f3
# file: f3
user.CB0="Some text for CB0"
user.GK0="Some text for GK0"
user.MY0="Some text for MY0"

-------------
So - the same "accumulation" way...
Is that an indented behaviour, or is it just a bug?

I think - a _copy_ ... is a 100% copy of the source - point.
To me, it's also a security bug - cause former data is still present!.

Best wishes - Guenter Kukkukk

btw - I already sent some info about that to Andreas Gruenbacher,
no reply so far. :-(