Dominique Devienne wrote:
From: Steve Loughran [mailto:[EMAIL PROTECTED]
well, it'd be nice if we could get/set unix file permissions; that is
the most important thing to me, symlinks would be good too. There are no
real symlinks in NTFS, though hard links are allowed in the same
filesystem.
What about NTFS 'junctions' or 'reparse points' Steve?
These smell symlink to me, no? --DD
http://shell-shocked.org/article.php?id=284
Ha, you are trying to catch me out.
while I reserve the right to be wrong, in this case I dont think I am.
As far as I am aware, they are effectively mount points; you can mount a
new drive under c://users/something and the rest of drive C is unware of
it, unless you do something filesys intensive and it suddenly gets a lot
slower. I remember under win2k-no-SP delete didnt work properly, but I
assume that is fixed now. (pause, no the article shows one problem, rm
the link tries to delete the stuff underneath in explorer. Also windows
shell treats drag and drop within a drive (its a move) differently from
across drives (its a copy); reparsing may change semantics back to movement.
So while reparse points are symlink-ish, they are primarily there to let
you
-mount new drives under a big drive for server side stuff
-add redirection for the fairly fancy NTFS distributed filesystem stuff,
Trivia point #1: remember that Win2K is multipersonality; there is
support for a (crippled) posix subsystem that is not a layer on top of
win32 (like cygwin or java), but talks straight to the kernel. the posix
mode has a different job inheritance pattern (you can fork, forked
things are children). The posix subsystem supported hard links since
nt3.1, while Win32 only officially added it in Win2K. Yet there was a
back door that let you create hard links in win32, which was somewhere
in the backup api, some IOCTL or something.
Trivia point #2: Win2K actually has a distributed link tracking service
by default. If you give a file an object id (IOCTL_SET_OID or something
similar), then when the file moves around, the DLTS tracks it. this lets
other apps find it by asking for the OID, and not the name. And here is
the cool thing: it works across network drives; you can move an
OID-tagged file to a lan drive, and things that use OIDs will not break!
Of course, nobody actually uses OIDs except bits of COM, and the Dist
Link Tracking Service is one of the first NT Services I turn off on a
new system, right after DRM-device-identifier.
Trivia point #3. NTFS supports multiple resource forks in a file, like
MacOS.
echo test > file:2
to put something into a resource named "2" alongside the base resource
(0). Again, nothing uses this except for some IIS security holes. We
dont have support in Ant (":" is treated as special), and I have never
tested java support anyway.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
