30 Nov
2005
30 Nov
'05
9:31 p.m.
I was just wondering, if we could implement symbolic links in ReactOS.
As I don't want to add this feature to every filesystem that doesn't
support symbolic links, I thought about another way.
I had two ideas:
1. Use a file for this, comparable to files like HOSTS etc
2. Use the registry
The more I thought about this, I liked my second idea more than my first
and noticed what a great thing the registry is.
We could simply add keys like HKEY_LOCAL_MACHINE\SYSTEM\symlinks\C:\My
Files and set the target directory as it's value.
It's very easy to search for such keys, so it shouldn't be that hard to
implement it into the IFS-driver.
More complicated would be the implementation into explorer and the
creation of a commandline utility.
A second feature could be to create such links for every user, so that
every user could use C:\My Files\... which would be linked to
C:\Documents and Settings\Username\My Files\... and he wouldn't even notice.
I think that would be a nice feature and I would really like to
implement this, but I'm afraid I can't do this alone, as I don't have
much experience and I'm just beginning to learn C++ and asm, so it would
be nice, if someone of you who likes this idea could help me with this.
Greets,
David Hinz
30 Nov
30 Nov
9:46 p.m.
Why not include a system service that implements a metadata server to
create the symlinks for you. It would be simple to do with a
sleepycat db or embedded mysql engine. Of course the links would have
to be accessible by other processes and applications to be add to the
whole experience. Or wait until an NTFS port comes into works and
then implement symlinks then... Either way they are going to have to
be written into the filesystem one way or the other.
On Nov 30, 2005, at 3:31 PM, David Hinz wrote:
I was just wondering, if we could implement symbolic
links in ReactOS.
As I don't want to add this feature to every filesystem that
doesn't support symbolic links, I thought about another way.
I had two ideas:
1. Use a file for this, comparable to files like HOSTS etc
2. Use the registry
The more I thought about this, I liked my second idea more than my
first and noticed what a great thing the registry is.
We could simply add keys like HKEY_LOCAL_MACHINE\SYSTEM\symlinks\C:
\My Files and set the target directory as it's value.
It's very easy to search for such keys, so it shouldn't be that
hard to implement it into the IFS-driver.
More complicated would be the implementation into explorer and the
creation of a commandline utility.
A second feature could be to create such links for every user, so
that every user could use C:\My Files\... which would be linked to
C:\Documents and Settings\Username\My Files\... and he wouldn't
even notice.
I think that would be a nice feature and I would really like to
implement this, but I'm afraid I can't do this alone, as I don't
have much experience and I'm just beginning to learn C++ and asm,
so it would be nice, if someone of you who likes this idea could
help me with this.
Greets,
David Hinz
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
10:08 p.m.
Why should I implement a service that provides me a db if I could just
use the registry, that works perfectly?
This service would make sense if we would use it for other purposes like
additional informations about files and so on, but I think my idea is
much more easier to implement.
I don't say, it's the best for the future, but it is capable of what I
want it to be, doesn't need many resources and adds a nice feature to
ROS, NT was always lacking.
And I don't want to wait until an NTFS port comes into works, because
that might be in 3 or 4 years and who knows what filesystems we are
using then... maybe already our own, created by Hans Reiser, because I
hates Linus Torvalds for not integrating Reiser4 into the Linux kernel
and wants revenge... who knows, but such a FS would be very fast...
Enough ot...
What I wanted to say is, I want ROS to be capable of symlinks and this
completely independent of the FS it is using.
I think theres no need to implement this into the FS, maybe wo could
write a backup of these regkeys to the harddisk, so they can be imported
into other ROS-installations, but that's not that important now.
Greets,
David Hinz
Rick Langschultz schrieb:
Why not include a system service that implements a
metadata server to
create the symlinks for you. It would be simple to do with a sleepycat
db or embedded mysql engine. Of course the links would have to be
accessible by other processes and applications to be add to the whole
experience. Or wait until an NTFS port comes into works and then
implement symlinks then... Either way they are going to have to be
written into the filesystem one way or the other.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
11:57 p.m.
Use the registry? For symbolic links? Extra file info? Are you
kidding me? You DO know why Windows tends to slow down over time
right? Over the months/years the registry gets more and more cluttered
with...junk. What happens when you delete a file? What happens if the
file gets nuked via a disk error? What happens if a user doesn't WANT
symbolic links taking up precious memory (and just because you can get
a GB of RAM for $70, a 200 GB HD for under $100, doesn't mean you
should try and use all that space on operating system code. See Vista
for an example*)
A service with an integrated db engine is the best way to go if you want
to do that, but please remember that NTFS already has support for
symbolic links.
Not to say that your idea isn't a good one...it's just better off as a
system service, as suggested earlier.
David Hinz wrote:
Why should I implement a service that provides me a db
if I could just
use the registry, that works perfectly?
This service would make sense if we would use it for other purposes
like additional informations about files and so on, but I think my
idea is much more easier to implement.
I don't say, it's the best for the future, but it is capable of what I
want it to be, doesn't need many resources and adds a nice feature to
ROS, NT was always lacking.
And I don't want to wait until an NTFS port comes into works, because
that might be in 3 or 4 years and who knows what filesystems we are
using then... maybe already our own, created by Hans Reiser, because I
hates Linus Torvalds for not integrating Reiser4 into the Linux kernel
and wants revenge... who knows, but such a FS would be very fast...
Enough ot...
What I wanted to say is, I want ROS to be capable of symlinks and this
completely independent of the FS it is using.
I think theres no need to implement this into the FS, maybe wo could
write a backup of these regkeys to the harddisk, so they can be
imported into other ROS-installations, but that's not that important now.
Greets,
David Hinz
Rick Langschultz schrieb:
Why not include a system service that implements
a metadata server to
create the symlinks for you. It would be simple to do with a
sleepycat db or embedded mysql engine. Of course the links would have
to be accessible by other processes and applications to be add to the
whole experience. Or wait until an NTFS port comes into works and
then implement symlinks then... Either way they are going to have to
be written into the filesystem one way or the other.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
1 Dec
1 Dec
12:37 a.m.
I was thinking more of a self-optimizing database service that would
allow indexing of files, submitting and retreiving metadata
information, extended file permissions and DRM (evil) if needed. Also
it could be built on something small like MySQL with an InnoDB
backend or even sleepycats or perhaps MaxDB from Mysql because they
provide the XML indexing engine which could prove very useful when
modifying data through notepad. Also the service could be controlled
like Spotlight in Mac OS X Tiger. This indexing service could index
different file types also and symbolic links would hold higher
privilege that indexed files. Using the registry is illogical because
the system goes through each of those keys on startup and loading...
Also with a new explorer interface the XML engine could interact with
explorer and the desktop in an attempt to create a better ReactOS
interface.
On Nov 30, 2005, at 5:57 PM, Richard wrote:
Use the registry? For symbolic links? Extra file
info? Are you
kidding me? You DO know why Windows tends to slow down over time
right? Over the months/years the registry gets more and more
cluttered with...junk. What happens when you delete a file? What
happens if the file gets nuked via a disk error? What happens if a
user doesn't WANT symbolic links taking up precious memory (and
just because you can get a GB of RAM for $70, a 200 GB HD for
under $100, doesn't mean you should try and use all that space on
operating system code. See Vista for an example*)
A service with an integrated db engine is the best way to go if you
want to do that, but please remember that NTFS already has support
for symbolic links.
Not to say that your idea isn't a good one...it's just better off
as a system service, as suggested earlier.
David Hinz wrote:
Why should I implement a service that provides me
a db if I could
just use the registry, that works perfectly?
This service would make sense if we would use it for other
purposes like additional informations about files and so on, but I
think my idea is much more easier to implement.
I don't say, it's the best for the future, but it is capable of
what I want it to be, doesn't need many resources and adds a nice
feature to ROS, NT was always lacking.
And I don't want to wait until an NTFS port comes into works,
because that might be in 3 or 4 years and who knows what
filesystems we are using then... maybe already our own, created by
Hans Reiser, because I hates Linus Torvalds for not integrating
Reiser4 into the Linux kernel and wants revenge... who knows, but
such a FS would be very fast...
Enough ot...
What I wanted to say is, I want ROS to be capable of symlinks and
this completely independent of the FS it is using.
I think theres no need to implement this into the FS, maybe wo
could write a backup of these regkeys to the harddisk, so they can
be imported into other ROS-installations, but that's not that
important now.
Greets,
David Hinz
Rick Langschultz schrieb:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev Why not include a system service that implements
a metadata
server to create the symlinks for you. It would be simple to do
with a sleepycat db or embedded mysql engine. Of course the links
would have to be accessible by other processes and applications
to be add to the whole experience. Or wait until an NTFS port
comes into works and then implement symlinks then... Either way
they are going to have to be written into the filesystem one way
or the other.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
1:08 p.m.
Well, if you add these features or plan to add them in the near future,
the service with the MySQL or whatever db would be better for this, I
just said that I like my idea more than yours, because it is easier to
implement.
It is true, that the registry would become larger by this, but how many
symbolic links do you want to use? 10000?
I think there wouldn't be much more than 100 of those links (and if
there were many more, it would just show, how important this feature
was...), so how slow would a PC have to be that this feature would slow
it measurably down?
To say it again, the idea with the db is good, but it is only better
than mine, if you really want to implement the features you mentioned,
because otherwise it would waste a lot of cpu-time and RAM.
@Richard: Windows doesn't slow down because of the registry (the german
pc-magazine c't prooved that some months ago), I think it is because of
full and very fragmented harddisks...
Greets,
David Hinz
Rick Langschultz schrieb:
I was thinking more of a self-optimizing database
service that would
allow indexing of files, submitting and retreiving metadata information,
extended file permissions and DRM (evil) if needed. Also it could be
built on something small like MySQL with an InnoDB backend or even
sleepycats or perhaps MaxDB from Mysql because they provide the XML
indexing engine which could prove very useful when modifying data
through notepad. Also the service could be controlled like Spotlight in
Mac OS X Tiger. This indexing service could index different file types
also and symbolic links would hold higher privilege that indexed files.
Using the registry is illogical because the system goes through each of
those keys on startup and loading...
Also with a new explorer interface the XML engine could interact with
explorer and the desktop in an attempt to create a better ReactOS
interface.
On Nov 30, 2005, at 5:57 PM, Richard wrote:
> Use the registry? For symbolic links? Extra file info? Are you
> kidding me? You DO know why Windows tends to slow down over time
> right? Over the months/years the registry gets more and more
> cluttered with...junk. What happens when you delete a file? What
> happens if the file gets nuked via a disk error? What happens if a
> user doesn't WANT symbolic links taking up precious memory (and just
> because you can get a GB of RAM for $70, a 200 GB HD for under $100,
> doesn't mean you should try and use all that space on operating system
> code. See Vista for an example*)
>
> A service with an integrated db engine is the best way to go if you
> want to do that, but please remember that NTFS already has support for
> symbolic links.
>
> Not to say that your idea isn't a good one...it's just better off as a
> system service, as suggested earlier.
3:15 p.m.
It is a very good idea to implement symbolic links in the registry;
however, i do find it very difficult to navigate a registry key with
hundreds of subkeys. Instead I would rather the system choose how to
index the data. Understandibly CPU load and RAM are key factors in
implementing such a service but until system services are implemented
i find it difficult to complete my part of the feature. Using the
registry now is a great place to start. However without rewriting
Explorer to interpret those links it will take some amount of time.
On Dec 1, 2005, at 7:08 AM, David Hinz wrote:
Well, if you add these features or plan to add them in
the near
future, the service with the MySQL or whatever db would be better
for this, I just said that I like my idea more than yours, because
it is easier to implement.
It is true, that the registry would become larger by this, but how
many symbolic links do you want to use? 10000?
I think there wouldn't be much more than 100 of those links (and if
there were many more, it would just show, how important this
feature was...), so how slow would a PC have to be that this
feature would slow it measurably down?
To say it again, the idea with the db is good, but it is only
better than mine, if you really want to implement the features you
mentioned, because otherwise it would waste a lot of cpu-time and RAM.
@Richard: Windows doesn't slow down because of the registry (the
german pc-magazine c't prooved that some months ago), I think it is
because of full and very fragmented harddisks...
Greets,
David Hinz
Rick Langschultz schrieb:
I was thinking more of a self-optimizing database
service that
would allow indexing of files, submitting and retreiving metadata
information, extended file permissions and DRM (evil) if needed.
Also it could be built on something small like MySQL with an
InnoDB backend or even sleepycats or perhaps MaxDB from Mysql
because they provide the XML indexing engine which could prove
very useful when modifying data through notepad. Also the service
could be controlled like Spotlight in Mac OS X Tiger. This
indexing service could index different file types also and
symbolic links would hold higher privilege that indexed files.
Using the registry is illogical because the system goes through
each of those keys on startup and loading...
Also with a new explorer interface the XML engine could interact
with explorer and the desktop in an attempt to create a better
ReactOS interface.
On Nov 30, 2005, at 5:57 PM, Richard wrote:
> Use the registry? For symbolic links? Extra file info? Are you
> kidding me? You DO know why Windows tends to slow down over time
> right? Over the months/years the registry gets more and more
> cluttered with...junk. What happens when you delete a file?
> What happens if the file gets nuked via a disk error? What
> happens if a user doesn't WANT symbolic links taking up precious
> memory (and just because you can get a GB of RAM for $70, a 200
> GB HD for under $100, doesn't mean you should try and use all
> that space on operating system code. See Vista for an example*)
>
> A service with an integrated db engine is the best way to go if
> you want to do that, but please remember that NTFS already has
> support for symbolic links.
>
> Not to say that your idea isn't a good one...it's just better off
> as a system service, as suggested earlier.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
3:25 p.m.
I don't have to change anything in explorer, I just have to add this
feature to IFS.
The only thing I could add to explorer is the ability of creating
symbolic links.
Greets,
David Hinz
Rick Langschultz schrieb:
It is a very good idea to implement symbolic links in
the registry;
however, i do find it very difficult to navigate a registry key with
hundreds of subkeys. Instead I would rather the system choose how to
index the data. Understandibly CPU load and RAM are key factors in
implementing such a service but until system services are implemented i
find it difficult to complete my part of the feature. Using the registry
now is a great place to start. However without rewriting Explorer to
interpret those links it will take some amount of time.
On Dec 1, 2005, at 7:08 AM, David Hinz wrote:
Well, if you add these features or plan to add
them in the near
future, the service with the MySQL or whatever db would be better for
this, I just said that I like my idea more than yours, because it is
easier to implement.
It is true, that the registry would become larger by this, but how
many symbolic links do you want to use? 10000?
I think there wouldn't be much more than 100 of those links (and if
there were many more, it would just show, how important this feature
was...), so how slow would a PC have to be that this feature would
slow it measurably down?
To say it again, the idea with the db is good, but it is only better
than mine, if you really want to implement the features you mentioned,
because otherwise it would waste a lot of cpu-time and RAM.
@Richard: Windows doesn't slow down because of the registry (the
german pc-magazine c't prooved that some months ago), I think it is
because of full and very fragmented harddisks...
Greets,
David Hinz
Rick Langschultz schrieb:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I was thinking more of a self-optimizing database
service that would
allow indexing of files, submitting and retreiving metadata
information, extended file permissions and DRM (evil) if needed. Also
it could be built on something small like MySQL with an InnoDB
backend or even sleepycats or perhaps MaxDB from Mysql because they
provide the XML indexing engine which could prove very useful when
modifying data through notepad. Also the service could be controlled
like Spotlight in Mac OS X Tiger. This indexing service could index
different file types also and symbolic links would hold higher
privilege that indexed files. Using the registry is illogical because
the system goes through each of those keys on startup and loading...
Also with a new explorer interface the XML engine could interact with
explorer and the desktop in an attempt to create a better ReactOS
interface.
On Nov 30, 2005, at 5:57 PM, Richard wrote:
> Use the registry? For symbolic links? Extra file info? Are you
> kidding me? You DO know why Windows tends to slow down over time
> right? Over the months/years the registry gets more and more
> cluttered with...junk. What happens when you delete a file? What
> happens if the file gets nuked via a disk error? What happens if a
> user doesn't WANT symbolic links taking up precious memory (and
> just because you can get a GB of RAM for $70, a 200 GB HD for under
> $100, doesn't mean you should try and use all that space on
> operating system code. See Vista for an example*)
>
> A service with an integrated db engine is the best way to go if you
> want to do that, but please remember that NTFS already has support
> for symbolic links.
>
> Not to say that your idea isn't a good one...it's just better off as
> a system service, as suggested earlier.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 
4 Dec
4 Dec
8:41 a.m.
I think the main problem when using the registry is
that the registry is part of the system itself and so
is alwalys saved on the system partition. If you
install ReactOS multiple times, you cannot have access
to the symbolic links created by another system.
So a part of the registry would have to be on every
logical partition affected by symbolic links. The
symbolic link has to be saved on the partition where
the real file is and on the partition where the
symbolic file is.
And you have to solve another problem: If someone
changes the partiton table, all names of the
partitions (like H: and also PhysicalDrivex) are
changed. So all symbolic links that go to another
partition couldn't be used any more.
tobitosso
--- David Hinz <post.center(a)gmail.com> schrieb:
I don't have to change anything in explorer, I
just
have to add this
feature to IFS.
The only thing I could add to explorer is the
ability of creating
symbolic links.
Greets,
David Hinz
Rick Langschultz schrieb:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
It is a very good idea to implement symbolic
links
in the registry;
however, i do find it very difficult to navigate
a
registry key with
hundreds of subkeys. Instead I would rather the
system choose how to
index the data. Understandibly CPU load and RAM
are key factors in
implementing such a service but until system
services are implemented i
find it difficult to complete my part of the
feature. Using the registry
now is a great place to start. However without
rewriting Explorer to
interpret those links it will take some amount of
time.
On Dec 1, 2005, at 7:08 AM, David Hinz wrote:
> Well, if you add these features or plan to add
them in the near
> future, the service with the MySQL or
whatever db
would be better for
> this, I just said that I like my idea more
than
yours, because it is
> easier to implement.
> It is true, that the registry would become larger
by this, but how
> many symbolic links do you want to use?
10000?
> I think there wouldn't be much more than 100 of
those links (and if
> there were many more, it would just show, how
important this feature
> was...), so how slow would a PC have to be
that
this feature would
> slow it measurably down?
>
> To say it again, the idea with the db is good,
but it is only better
> than mine, if you really want to implement
the
features you mentioned,
> because otherwise it would waste a lot of
cpu-time and RAM.
>
> @Richard: Windows doesn't slow down because of
the registry (the
> german pc-magazine c't prooved that some
months
ago), I think it is
> because of full and very fragmented
harddisks...
>
> Greets,
>
> David Hinz
>
> Rick Langschultz schrieb:
>> I was thinking more of a self-optimizing
database service that would
>> allow indexing of files, submitting and
retreiving metadata
>> information, extended file permissions
and DRM
(evil) if needed. Also
>> it could be built on something small like
MySQL
with an InnoDB
>> backend or even sleepycats or perhaps
MaxDB from
Mysql because they
>> provide the XML indexing engine which
could
prove very useful when
>> modifying data through notepad. Also the
service
could be controlled
>> like Spotlight in Mac OS X Tiger. This
indexing
service could index
>> different file types also and symbolic
links
would hold higher
>> privilege that indexed files. Using the
registry
is illogical because
>> the system goes through each of those
keys on
startup and loading...
>> Also with a new explorer interface the
XML
engine could interact with
>> explorer and the desktop in an attempt to
create
a better ReactOS
>> interface.
>> On Nov 30, 2005, at 5:57 PM, Richard wrote:
>>> Use the registry? For symbolic links? Extra
file info? Are you
>>> kidding me? You DO know why Windows
tends to
slow down over time
>>> right? Over the months/years the
registry gets
more and more
>>> cluttered with...junk. What happens
when you
delete a file? What
>>> happens if the file gets nuked via a
disk
error? What happens if a
>>> user doesn't WANT symbolic links
taking up
precious memory (and
>>> just because you can get a GB of RAM
for $70, a
200 GB HD for under
>>> $100, doesn't mean you should try
and use all
that space on
>>> operating system code. See Vista for
an
example*)
>>>
>>> A service with an integrated db engine is the
best way to go if you
>>> want to do that, but please remember
that NTFS
already has support
>>> for symbolic links.
>>>
>>> Not to say that your idea isn't a good
one...it's just better
off as
> a system service, as suggested earlier.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 
3 Dec
3 Dec
11:30 a.m.
David Hinz wrote:
I was just wondering, if we could implement symbolic
links in ReactOS.
As I don't want to add this feature to every filesystem that doesn't
support symbolic links, I thought about another way.
I had two ideas:
1. Use a file for this, comparable to files like HOSTS etc
2. Use the registry
NTFS supports Junctions, which are the same as symbolic links. Some
people say they're more like hardlinks, but hardlinks don't span
multiple drives or even network shares.
More info:
http://www.answers.com/topic/ntfs-junction-point
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524
http://www.sysinternals.com/Utilities/Junction.html
Expect the functionality to be there when ReactOS gets an NTFS driver.
mf
6920
days inactive
6924
days old
9 comments
5 participants
participants (5)
-
David Hinz -
mf -
Richard -
Rick Langschultz -
tobitosso