And for sure, it worked the first time.
Anyway, here is the patch.
It asserts on start-up when we pass a Unix-style path to
boost::filesystem in development/Win32/package.C, but you can just
ignore that, and it will work fine.
Regards,
Asger
lyx-devel.patch.bz2
Description: Binary data
Asger Ottar Alstrup wrote:
> And for sure, it worked the first time.
> Anyway, here is the patch.
Asger, could you commit this to the development/Win32 directory. I'm off
to the Alps for a week on Friday evening so my hacking-on-LyX time is
running out fast. It'll be easier to pick up where I l
Angus Leeming wrote:
Asger, could you commit this to the development/Win32 directory. I'm off
to the Alps for a week on Friday evening so my hacking-on-LyX time is
running out fast. It'll be easier to pick up where I left off if this
patch is in the repository.
Done. Elias just woke up, so I'm o
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| And for sure, it worked the first time.
>
| Anyway, here is the patch.
>
| It asserts on start-up when we pass a Unix-style path to
| boost::filesystem in development/Win32/package.C, but you can just
| ignore that, and it will work fine.
??
Comm
Lars Gullik Bjønnes wrote:
This version of is_readonly is racy. So for win32 we should try
to avoid this. An non-racy version would look like this? (right?)
bool is_readonly(patch const & ph)
{
DWORD const attr = ::GetFileAttributes(ph.string().c_str());
return (attr != INVALID_F
On Mon, Jan 31, 2005 at 02:23:54PM +0100, Lars Gullik Bj?nnes wrote:
> This version of is_readonly is racy. So for win32 we should try
All versions of is_readonly() are racy, it's implicit in the API.
regards
john
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Jan 31, 2005 at 02:23:54PM +0100, Lars Gullik Bj?nnes wrote:
>
>> This version of is_readonly is racy. So for win32 we should try
>
| All versions of is_readonly() are racy, it's implicit in the API.
Not if checking readonly is the only thing you
On Tue, Feb 01, 2005 at 11:46:17PM +0100, Lars Gullik Bj?nnes wrote:
> We shouldn't have to call readonly a lot anyway. The only place where
> I think it is "needed" is for informing the user that the loaded file
> is read only. For writing, we should just try to write.. and fail if
> we cannot do