Dangling symlink

[Warren Togami]

Not having seen libtorrent code, I'm guessing it passes paths through 
abstraction layers that are symlink-hostile even before it gets to 
boost::filesystem.  hydri may have better guidance on how exactly to 
handle symlinks.

* Replicate symlinks exactly as they exist in the source directory, 
including mtime of the symlink itself.
* Replicate even if they point at seemingly invalid paths and files. 
Often they point at ../somethingvalid while you are replicating only the 
current directory and you want to preserve that seemingly dangling symlink.

On 06/17/2009 11:35 PM, Atul Aggarwal wrote:
> nope, it is not recording correct time even for symlink. Even stat() is
> giving mtime of the file not of the link.
> I am thinking of submitting the patch for mtime first and work on
> symlink mtime in adding support for symlink in libtorrent. For symlink,
> i need to scan almost the whole code of creating torrent file as
> exceptions are thrown at various levels for dangling symlink and even
> for symlink pointing to a file, code is not working as expected (as it
> was not designed to handle symlink in the first place (maybe)).
>
> On Thu, Jun 18, 2009 at 2:20 AM, Warren Togami <wtogami at redhat.com
> <mailto:wtogami at redhat.com>> wrote:
>
>     Does it properly record the mtime of the symlink itself if the
>     symlink is dangling?
>
>     (pointing at a file that doesn't exist)
>
>     Warren
>
>
>
>
> --
> Regards,
>
> Atul Aggarwal