Just wanted to let you all know that the proposed solution is now in
the "symlinks" branch:
http://www.fossil-scm.org/index.html/timeline?r=symlinks
(I combined all my changes into a single commit -- hate to do this,
but I had some other public branches and files in my clone that I
didn't want
Just retried and I have to admit it did not work this time. Notepad
complained about the access being refused.
Strange, I probably did something wrong the first time. :)
Regards,
On Fri, Jan 28, 2011 at 2:02 PM, Heinrich Huss <
heinrich.h...@psh-consulting.de> wrote:
> Strange not on my sytstem
Strange not on my sytstem. A link to a directory remains a link to a
directory and a link to a file remains a link to a file.
Bothe cannot be swapped and i if try to access the one of the wron
type I get access denied.
It's Windows 7 Professional 64bit. I did these test as Adminitrator.
Ma
After the echo command, I tried "notepad i_am_a_link" (which was the name of
the link) and it opened the file.
The type may not be changed but the target is found anyway.
On Fri, Jan 28, 2011 at 1:49 PM, Heinrich Huss <
heinrich.h...@psh-consulting.de> wrote:
> In my test the link is still a lin
In my test the link is still a link to a directory .
if I try 'type linkname' it says 'access denied'.
Regards
Hein
Am 28.01.2011 um 19:16 schrieb Alexandre Sénéchal:
Yes, it just points to the newly created file. At least on Windows 7
64-bits. Note that you need elevated privilege to crea
On Jan 28, 2011, at 7:29 PM, Stephan Beal wrote:
> Which means fossil must run as a privileged user if it wants to support links.
>
> Can of Worms!
On Windows. With "allow-symlinks" option turned on.
If we implement it on Windows at all (that's why I didn't do it) :-)
--
Dmitry Chestnykh
2011/1/28 Alexandre Sénéchal
> Yes, it just points to the newly created file. At least on Windows 7
> 64-bits. Note that you need elevated privilege to create the link.
Which means fossil must run as a privileged user if it wants to support
links.
Can of Worms!
--
- stephan beal
http://w
On Fri, Jan 28, 2011 at 1:18 PM, Dmitry Chestnykh
wrote:
> On Jan 28, 2011, at 7:16 PM, Alexandre Sénéchal wrote:
>
> > Yes, it just points to the newly created file. At least on Windows 7
> 64-bits.
>
> Awesome. But I wonder why it needs "/d" flag then? :-)
>
That I cannot tell.
>
> > Note tha
On Jan 28, 2011, at 7:16 PM, Alexandre Sénéchal wrote:
> Yes, it just points to the newly created file. At least on Windows 7 64-bits.
Awesome. But I wonder why it needs "/d" flag then? :-)
> Note that you need elevated privilege to create the link.
This is bad.
--
Dmitry Chestnykh
__
Yes, it just points to the newly created file. At least on Windows 7
64-bits. Note that you need elevated privilege to create the link.
On Fri, Jan 28, 2011 at 1:11 PM, Dmitry Chestnykh
wrote:
> On Jan 28, 2011, at 7:02 PM, Alexandre Sénéchal wrote:
>
> > I just tried it out.
> > Seems to behave
On Jan 28, 2011, at 7:02 PM, Alexandre Sénéchal wrote:
> I just tried it out.
> Seems to behave like in Unix. The link stays and if used it will report that
> the file/directory cannot be found.
> In the case of the echo command, it creates a file and the link points to it.
So, if a link pointed
Hi,
I just tried it out.
Seems to behave like in Unix. The link stays and if used it will report that
the file/directory cannot be found.
In the case of the echo command, it creates a file and the link points to
it.
Best regards,
On Fri, Jan 28, 2011 at 12:43 PM, Dmitry Chestnykh
wrote:
> On
On Jan 28, 2011, at 6:37 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 6:26 PM, Dmitry Chestnykh
> wrote:
> $ ln -s randomfilename newlink
>
> We don't know what kind of link it is -- folder or file, because
> "randomfilename" doesn't exist.
>
> Not only that, if the file does exist and i
On Fri, Jan 28, 2011 at 6:26 PM, Dmitry Chestnykh
wrote:
> $ ln -s randomfilename newlink
>
> We don't know what kind of link it is -- folder or file, because
> "randomfilename" doesn't exist.
>
Not only that, if the file does exist and is subsequently removed or
replaced with the other type, wha
On Jan 28, 2011, at 18:18 , Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 6:03 PM, Remigiusz Modrzejewski wrote:
>
In that case the F-card access permissions could be extended further with
"ld" for link to directory and "lf" for link to file when the link is
first imported into
On Jan 28, 2011, at 6:05 PM, Doug Currie wrote:
>> But the target file or directory could not exist at all, so it won't solve
>> the problem.
> What is "the problem?" I thought the problem was knowing if the link to be
> created was to a directory or to a file.
Exactly. But we don't know if the
On Jan 28, 2011, at 6:03 PM, Remigiusz Modrzejewski wrote:
>>> In that case the F-card access permissions could be extended further with
>>> "ld" for link to directory and "lf" for link to file when the link is first
>>> imported into Fossil. This would matter only when the link is created in a
On Jan 28, 2011, at 11:52 AM, Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
>> Do all supported platforms have the equivalent of stat() to see if a linked
>> object is a directory or a file?
>>
>> In that case the F-card access permissions could be extended further w
On Jan 28, 2011, at 17:52 , Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
>> Do all supported platforms have the equivalent of stat() to see if a linked
>> object is a directory or a file?
>>
>> In that case the F-card access permissions could be extended further wit
On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
> Do all supported platforms have the equivalent of stat() to see if a linked
> object is a directory or a file?
>
> In that case the F-card access permissions could be extended further with
> "ld" for link to directory and "lf" for link to file wh
On Jan 28, 2011, at 9:55 AM, Ron Wilson wrote:
> On Fri, Jan 28, 2011 at 6:31 AM, Dmitry Chestnykh
> wrote:
>> For example, imagine checking in the link to "../README", where README is
>> located outside
>> our repository. What link should be created in this case on Windows --
>> directory sym
On Fri, Jan 28, 2011 at 6:31 AM, Dmitry Chestnykh
wrote:
> For example, imagine checking in the link to "../README", where README is
> located outside
> our repository. What link should be created in this case on Windows --
> directory symlink or
> file symlink?
Directory. For reasons in my ear
On Jan 28, 2011, at 3:01 PM, Joerg Sonnenberger wrote:
> This is actually not true. You can't open them in the win32 subsystem,
> the SFU subsystem isn't effected by the DOS legacy...
Well, it's also not true in case you run Fossil on Linux in VMware on Windows
:-)
--
Dmitry Chestnykh
___
On Fri, Jan 28, 2011 at 02:23:06PM +0100, Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 2:07 PM, Stephan Beal wrote:
>
> > Having empty text files "on platforms which do not support them" DOES
> > break the tree because the underlying files are now different (and
> > have different semantics) on
On Jan 28, 2011, at 2:07 PM, Stephan Beal wrote:
> Having empty text files "on platforms which do not support them" DOES
> break the tree because the underlying files are now different (and
> have different semantics) on different platforms. If i then copy such
> a checked-out source tree over
On Fri, Jan 28, 2011 at 1:52 PM, Dmitry Chestnykh
wrote:
> But we still _must_ handle them somehow. The current (pre-symlink) behavior
> depends on a "good" state of working directory -- that you won't use
> symlinks in an incompatible way. And you can discover the incompatible
> behavior only aft
On Jan 28, 2011, at 12:43 PM, Stephan Beal wrote:
> It cannot work transparently across platforms, period, and there are
> good reasons why so few source control systems attempt to version
> them. Symlinks are platform-specific convenience objects, and not a
> feature which can be portably emul
On Jan 28, 2011, at 12:43 PM, Stephan Beal wrote:
> i, for one, am against adding symlinks support for exactly these types of
> reasons. Too many questions regarding their portable use cannot be answered
> (and some of them are purely philosophical rather than technical, e.g.
> whether or not t
On Jan 28, 2011, at 12:43 , Stephan Beal wrote:
> i, for one, am against adding symlinks support for exactly these types of
> reasons. Too many questions regarding their portable use cannot be answered
> (and some of them are purely philosophical rather than technical, e.g.
> whether or not to al
On Fri, Jan 28, 2011 at 12:31 PM, Dmitry Chestnykh
wrote:
>
This will work when symlinks point to files/folders inside our repository,
> but what to do with other links?
> For example, imagine checking in the link to "../README", where README is
> located outside our repository. What link should
Now, the next major pain: Windows requires you to know whether the target path
of symlink is a directory or a file in order to create symlink. How to handle
this?
We cannot use Fossil's create_symlink() function during checkout, because when
checking out, some files may not yet exist. We can h
On Jan 28, 2011, at 9:33 AM, Petr Man wrote:
> On Fri, Jan 28, 2011 at 02:16, Dmitry Chestnykh
> wrote:
>> http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx
>
> I think it means 31 in depth.
Ah, good, thanks for clarifying. Then it's not that bad.
--
Dmitry Chestnykh
_
On Fri, Jan 28, 2011 at 02:16, Dmitry Chestnykh wrote:
> http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx
I think it means 31 in depth.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/
On Fri, Jan 28, 2011 at 06:19, Ron Wilson wrote:
> How about NTFS Junction Points? Those are supported in XP, which is
> the version of Windows we need to use where I work.
>
> Also, unlike shortcuts, they are transparent to applications that are
> unaware of them - much like real symlinks.
They
On Thu, Jan 27, 2011 at 6:58 PM, Petr Man wrote:
> As per http://en.wikipedia.org/wiki/NTFS_symbolic_link, the support
> for symlinks exists from Vista up. I would therefore be inclined in
> using that instead of that awful undocumented binary fake something
> called shortcuts.
How about NTFS Jun
On Jan 28, 2011, at 1:39 AM, Petr Man wrote:
> I just made 33 symlinks, no error, all work. Where did you find this?
> I must have missed it.
Hm, interesting. I've read this here:
http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx
which is linked from this Wikipedia article:
http://en
On Fri, Jan 28, 2011 at 01:33, Dmitry Chestnykh wrote:
> On Vista there's a limit of 31* symlinks per directory, so I
> guess it's not really an option. I'm not sure what behavior would be
> if there are more than 31 symlinks in repository -- throw an error?
I just made 33 symlinks, no error, al
On Jan 28, 2011, at 12:58 AM, Petr Man wrote:
> As per http://en.wikipedia.org/wiki/NTFS_symbolic_link, the support
> for symlinks exists from Vista up.
On Vista there's a limit of 31* symlinks per directory, so I
guess it's not really an option. I'm not sure what behavior would be
if there are
On Wed, Jan 26, 2011 at 23:55, Dmitry Chestnykh wrote:
> I heard that Windows 7 supports symlinks, but I don't have this
> version (I test on XP). So there's a possibility that some Windows
> developer could add full symlink support to Fossil on Windows 7.
>
> Another way would be to add some kin
On Thu, Jan 27, 2011 at 12:13 PM, Dmitry Chestnykh
wrote:
>
> - Shortcuts on Windows are mostly for users -- that is, programs
> don't handle them as well as Unix programs handle symlinks (by
> following them by default).
I had forgotten that. As I recall, open() on a symlink automatically
follo
On Jan 27, 2011, at 5:21 AM, Ron Wilson wrote:
> That said, where the target of a symlink is a directory, it would make
> sense to create a Windows shortcut.
I thought about handling symlinks as shortcuts on Windows, but
decided against this idea. I think it would create more problems that
it w
On Jan 26, 2011, at 23:55 , Dmitry Chestnykh wrote:
> I'm working on adding symlink support to Fossil, mostly because having
> it is very important for my Mac development, where I put frameworks
> into repository, and valid frameworks on Mac contain at least 3
> symlink inside them. Plus, there w
Symlink support makes sense and would be useful.
As for Windows, I only use it when I have to (which is most days,
unfortunately).
That said, where the target of a symlink is a directory, it would make
sense to create a Windows shortcut. In a software development
environment like where I work, th
Hello,
I'm working on adding symlink support to Fossil, mostly because having
it is very important for my Mac development, where I put frameworks
into repository, and valid frameworks on Mac contain at least 3
symlink inside them. Plus, there were requests for this feature in the
past. Currently F
44 matches
Mail list logo
