From alan.schmitt at polytechnique.org Thu Jun 7 13:21:50 2007
From: alan.schmitt at polytechnique.org (Alan Schmitt)
Date: Thu, 7 Jun 2007 19:21:50 +0200
Subject: [Unison-hackers] Progress bar overflow with current uimacnew?
Message-ID: <10F348CA-88E3-4906-8576-404BC6FE3495@polytechnique.org>
Hello,
I've noticed a cosmetic bug with the current version of uimacnew.
When the amount of data to transfer is pretty big (I've just seen it
with 1.2 GB), then the progress bar may fill up quickly, then become
negative (it becomes larger on the left, overwriting the "Size"
column), then it shortens, and it starts filling up again. This looks
like some kind of integer overflow.
Have you noticed this as well?
Alan
--
Alan Schmitt
The hacker: someone who figured things out and made something cool
happen.
.O.
..O
OOO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070607/d70918d7/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: =?ISO-8859-1?Q?Questa_=E8_un_messaggio_firmato_elettronicamente?=
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070607/d70918d7/PGP-0001.sig
From aogriffiths at gmail.com Fri Jun 22 06:40:01 2007
From: aogriffiths at gmail.com (Adam Griffiths)
Date: Fri, 22 Jun 2007 11:40:01 +0100
Subject: [Unison-hackers] [unison-users] unison.tmp files
In-Reply-To:
References:
Message-ID:
OK i see. I have never programed caml before so I'm a bit stuck. I looks
like I need to edit lines some of the stuff between 368..382 and 137..147
could anyone help me workout what changes to make?
Thanks
Adam
PS, it seems more appropriate to continue this thread on the unison-hackers
mailing list.
On 21/06/07, Benjamin Pierce wrote:
>
> You'd need to rewrite some code involving tempFileSuffix in the file
> os.ml...
>
> Regards,
>
> - Benjamin
>
> On Jun 21, 2007, at 11:40 AM, Adam wrote:
>
> > Hi I am working with a document storage system called "LiveLink". I
> > assess all LiveLink documents over WebDAV mounted as a network drive
> > in windows. When I am out of the office I am keeping an offline
> > replica of these files in case I need to read or edit them. I am
> > using unison to maintain the replica between the offline copy on my
> > laptop D:\ drive and the webdav copy mounted on a network share Z:\.
> >
> > This works fine... except...
> >
> > LiveLink does something special. When ever you create a file LiveLink
> > records some metadata about it, including its MIME type. All files
> > uploaded by unison are copied to LiveLink with a unison.tmp
> > extension, so LiveLink sets the MIME type as application/octet-
> > stream. Unison then renames the file to have it's correct extension,
> > say ".doc" (which should have a MIME type of application/msword) but
> > LiveLink does not update the metadata on rename, it only sets it at
> > the time the file is created.
> >
> > This leaves me having used unison to upload multiple .doc .xls .mpp
> > files (all ms document formats) into LiveLink and live link having
> > them set with the wrong MIME type - so whenever anyone I work with
> > trys to download them the browser is told they are application/octet-
> > stream files and saves them as .doc.bin .doc.xls .doc.mpp
> > respectively.
> >
> > Is there anything I can do to prevent this. The organisation I work
> > for (and the organisation that builds LiveLink) are large and are not
> > going to change LiveLink to be more compatible with unison I'm
> > afraid. What I'm really looking for is a unison option or hack that
> > uploads the files with the correct extension.
> >
> > Thanks
> >
> > Adam
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> > <*> To visit your group on the web, go to:
> > http://groups.yahoo.com/group/unison-users/
> >
> > <*> Your email settings:
> > Individual Email | Traditional
> >
> > <*> To change settings online go to:
> > http://groups.yahoo.com/group/unison-users/join
> > (Yahoo! ID required)
> >
> > <*> To change settings via email:
> > mailto:unison-users-digest at yahoogroups.com
> > mailto:unison-users-fullfeatured at yahoogroups.com
> >
> > <*> To unsubscribe from this group, send an email to:
> > unison-users-unsubscribe at yahoogroups.com
> >
> > <*> Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070622/60ef12d2/attachment.htm
From aogriffiths at gmail.com Fri Jun 22 13:21:34 2007
From: aogriffiths at gmail.com (Adam Griffiths)
Date: Fri, 22 Jun 2007 18:21:34 +0100
Subject: [Unison-hackers] [unison-users] unison.tmp files
In-Reply-To:
References:
Message-ID:
Ok, with my 1 hour old ocaml skills i have fixed my problem by putting all
the temp file info in the suffix rather than the prefix. This then lets the
file extension remain invariant thuoghout the copy raname procedure.
Note, this is based on unison-2.13.16
diff unison-2.13.16/os.ml unison-2.13.16_a/os.ml
375c375
< (Path.addSuffixToFinalName path s)
---
> (Path.addPrefixToFinalName path s)
However
This leaves problems with the consistency of the code. Fisrt off
tempFileSuffix is no loger used as a suffix so the namingis inconsistent and
second off lines 138 and 139 are checking for files that end in
tempFileSuffix, which will never exists.
Given my unison design and ocaml knowlege is very basic can anyone:
a) let me know if my code change will cause anu disasters if I use it
b) suggest a putter code patch to solve my problem?
Thanks
Adam
On 22/06/07, Adam Griffiths wrote:
>
> OK i see. I have never programed caml before so I'm a bit stuck. I looks
> like I need to edit lines some of the stuff between 368..382 and 137..147
> could anyone help me workout what changes to make?
>
> Thanks
>
> Adam
>
> PS, it seems more appropriate to continue this thread on the
> unison-hackers mailing list.
>
>
> On 21/06/07, Benjamin Pierce wrote:
> >
> > You'd need to rewrite some code involving tempFileSuffix in the file
> > os.ml...
> >
> > Regards,
> >
> > - Benjamin
> >
> > On Jun 21, 2007, at 11:40 AM, Adam wrote:
> >
> > > Hi I am working with a document storage system called "LiveLink". I
> > > assess all LiveLink documents over WebDAV mounted as a network drive
> > > in windows. When I am out of the office I am keeping an offline
> > > replica of these files in case I need to read or edit them. I am
> > > using unison to maintain the replica between the offline copy on my
> > > laptop D:\ drive and the webdav copy mounted on a network share Z:\.
> > >
> > > This works fine... except...
> > >
> > > LiveLink does something special. When ever you create a file LiveLink
> > > records some metadata about it, including its MIME type. All files
> > > uploaded by unison are copied to LiveLink with a unison.tmp
> > > extension, so LiveLink sets the MIME type as application/octet-
> > > stream. Unison then renames the file to have it's correct extension,
> > > say ".doc" (which should have a MIME type of application/msword) but
> > > LiveLink does not update the metadata on rename, it only sets it at
> > > the time the file is created.
> > >
> > > This leaves me having used unison to upload multiple .doc .xls .mpp
> > > files (all ms document formats) into LiveLink and live link having
> > > them set with the wrong MIME type - so whenever anyone I work with
> > > trys to download them the browser is told they are application/octet-
> > > stream files and saves them as .doc.bin .doc.xls .doc.mpp
> > > respectively.
> > >
> > > Is there anything I can do to prevent this. The organisation I work
> > > for (and the organisation that builds LiveLink) are large and are not
> > > going to change LiveLink to be more compatible with unison I'm
> > > afraid. What I'm really looking for is a unison option or hack that
> > > uploads the files with the correct extension.
> > >
> > > Thanks
> > >
> > > Adam
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > > <*> To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/unison-users/
> > >
> > > <*> Your email settings:
> > > Individual Email | Traditional
> > >
> > > <*> To change settings online go to:
> > > http://groups.yahoo.com/group/unison-users/join
> > > (Yahoo! ID required)
> > >
> > > <*> To change settings via email:
> > > mailto: unison-users-digest at yahoogroups.com
> > > mailto:unison-users-fullfeatured at yahoogroups.com
> > >
> > > <*> To unsubscribe from this group, send an email to:
> > > unison-users-unsubscribe at yahoogroups.com
> > >
> > > <*> Your use of Yahoo! Groups is subject to:
> > > http://docs.yahoo.com/info/terms/
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070622/64937102/attachment.htm
From bcpierce at cis.upenn.edu Fri Jun 22 13:49:50 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Fri, 22 Jun 2007 13:49:50 -0400
Subject: [Unison-hackers] [unison-users] unison.tmp files
In-Reply-To:
References:
Message-ID:
I think the main issue with this partial fix will be that, if Unison
is interrupted, then any temp files from this run will not be
recognized as such and the next run will try to propagate them
instead of deleting them. This could be worked around using the
"ignore" preference.
- Benjamin
On Jun 22, 2007, at 1:21 PM, Adam Griffiths wrote:
> Ok, with my 1 hour old ocaml skills i have fixed my problem by
> putting all the temp file info in the suffix rather than the
> prefix. This then lets the file extension remain invariant
> thuoghout the copy raname procedure.
>
> Note, this is based on unison-2.13.16
>
> diff unison-2.13.16/os.ml unison-2.13.16_a/os.ml
> 375c375
> < (Path.addSuffixToFinalName path s)
> ---
> > (Path.addPrefixToFinalName path s)
>
> However
>
> This leaves problems with the consistency of the code. Fisrt off
> tempFileSuffix is no loger used as a suffix so the namingis
> inconsistent and second off lines 138 and 139 are checking for
> files that end in tempFileSuffix, which will never exists.
>
> Given my unison design and ocaml knowlege is very basic can anyone:
>
> a) let me know if my code change will cause anu disasters if I use it
> b) suggest a putter code patch to solve my problem?
>
> Thanks
>
> Adam
>
>
> On 22/06/07, Adam Griffiths wrote:
> OK i see. I have never programed caml before so I'm a bit stuck. I
> looks like I need to edit lines some of the stuff between 368..382
> and 137..147 could anyone help me workout what changes to make?
>
> Thanks
>
> Adam
>
> PS, it seems more appropriate to continue this thread on the unison-
> hackers mailing list.
>
>
> On 21/06/07, Benjamin Pierce wrote: You'd
> need to rewrite some code involving tempFileSuffix in the file
> os.ml...
>
> Regards,
>
> - Benjamin
>
> On Jun 21, 2007, at 11:40 AM, Adam wrote:
>
> > Hi I am working with a document storage system called "LiveLink". I
> > assess all LiveLink documents over WebDAV mounted as a network drive
> > in windows. When I am out of the office I am keeping an offline
> > replica of these files in case I need to read or edit them. I am
> > using unison to maintain the replica between the offline copy on my
> > laptop D:\ drive and the webdav copy mounted on a network share Z:\.
> >
> > This works fine... except...
> >
> > LiveLink does something special. When ever you create a file
> LiveLink
> > records some metadata about it, including its MIME type. All files
> > uploaded by unison are copied to LiveLink with a unison.tmp
> > extension, so LiveLink sets the MIME type as application/octet-
> > stream. Unison then renames the file to have it's correct extension,
> > say ".doc" (which should have a MIME type of application/msword) but
> > LiveLink does not update the metadata on rename, it only sets it at
> > the time the file is created.
> >
> > This leaves me having used unison to upload multiple .doc .xls .mpp
> > files (all ms document formats) into LiveLink and live link having
> > them set with the wrong MIME type - so whenever anyone I work with
> > trys to download them the browser is told they are application/
> octet-
> > stream files and saves them as .doc.bin .doc.xls .doc.mpp
> > respectively.
> >
> > Is there anything I can do to prevent this. The organisation I work
> > for (and the organisation that builds LiveLink) are large and are
> not
> > going to change LiveLink to be more compatible with unison I'm
> > afraid. What I'm really looking for is a unison option or hack that
> > uploads the files with the correct extension.
> >
> > Thanks
> >
> > Adam
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> > <*> To visit your group on the web, go to:
> > http://groups.yahoo.com/group/unison-users/
> >
> > <*> Your email settings:
> > Individual Email | Traditional
> >
> > <*> To change settings online go to:
> > http://groups.yahoo.com/group/unison-users/join
> > (Yahoo! ID required)
> >
> > <*> To change settings via email:
> > mailto: unison-users-digest at yahoogroups.com
> > mailto:unison-users-fullfeatured at yahoogroups.com
> >
> > <*> To unsubscribe from this group, send an email to:
> > unison-users-unsubscribe at yahoogroups.com
> >
> > <*> Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
> >
>
>
>
From aogriffiths at gmail.com Mon Jun 25 04:59:02 2007
From: aogriffiths at gmail.com (Adam Griffiths)
Date: Mon, 25 Jun 2007 09:59:02 +0100
Subject: [Unison-hackers] [unison-users] unison.tmp files
In-Reply-To:
References:
Message-ID:
I agree, is there anywhere in the code other than lines 137..147 of
os.mlwhere this needs to be addressed?
Thanks
Adam
On 22/06/07, Benjamin Pierce wrote:
>
> I think the main issue with this partial fix will be that, if Unison
> is interrupted, then any temp files from this run will not be
> recognized as such and the next run will try to propagate them
> instead of deleting them. This could be worked around using the
> "ignore" preference.
>
> - Benjamin
>
> On Jun 22, 2007, at 1:21 PM, Adam Griffiths wrote:
>
> > Ok, with my 1 hour old ocaml skills i have fixed my problem by
> > putting all the temp file info in the suffix rather than the
> > prefix. This then lets the file extension remain invariant
> > thuoghout the copy raname procedure.
> >
> > Note, this is based on unison-2.13.16
> >
> > diff unison-2.13.16/os.ml unison-2.13.16_a/os.ml
> > 375c375
> > < (Path.addSuffixToFinalName path s)
> > ---
> > > (Path.addPrefixToFinalName path s)
> >
> > However
> >
> > This leaves problems with the consistency of the code. Fisrt off
> > tempFileSuffix is no loger used as a suffix so the namingis
> > inconsistent and second off lines 138 and 139 are checking for
> > files that end in tempFileSuffix, which will never exists.
> >
> > Given my unison design and ocaml knowlege is very basic can anyone:
> >
> > a) let me know if my code change will cause anu disasters if I use it
> > b) suggest a putter code patch to solve my problem?
> >
> > Thanks
> >
> > Adam
> >
> >
> > On 22/06/07, Adam Griffiths wrote:
> > OK i see. I have never programed caml before so I'm a bit stuck. I
> > looks like I need to edit lines some of the stuff between 368..382
> > and 137..147 could anyone help me workout what changes to make?
> >
> > Thanks
> >
> > Adam
> >
> > PS, it seems more appropriate to continue this thread on the unison-
> > hackers mailing list.
> >
> >
> > On 21/06/07, Benjamin Pierce wrote: You'd
> > need to rewrite some code involving tempFileSuffix in the file
> > os.ml...
> >
> > Regards,
> >
> > - Benjamin
> >
> > On Jun 21, 2007, at 11:40 AM, Adam wrote:
> >
> > > Hi I am working with a document storage system called "LiveLink". I
> > > assess all LiveLink documents over WebDAV mounted as a network drive
> > > in windows. When I am out of the office I am keeping an offline
> > > replica of these files in case I need to read or edit them. I am
> > > using unison to maintain the replica between the offline copy on my
> > > laptop D:\ drive and the webdav copy mounted on a network share Z:\.
> > >
> > > This works fine... except...
> > >
> > > LiveLink does something special. When ever you create a file
> > LiveLink
> > > records some metadata about it, including its MIME type. All files
> > > uploaded by unison are copied to LiveLink with a unison.tmp
> > > extension, so LiveLink sets the MIME type as application/octet-
> > > stream. Unison then renames the file to have it's correct extension,
> > > say ".doc" (which should have a MIME type of application/msword) but
> > > LiveLink does not update the metadata on rename, it only sets it at
> > > the time the file is created.
> > >
> > > This leaves me having used unison to upload multiple .doc .xls .mpp
> > > files (all ms document formats) into LiveLink and live link having
> > > them set with the wrong MIME type - so whenever anyone I work with
> > > trys to download them the browser is told they are application/
> > octet-
> > > stream files and saves them as .doc.bin .doc.xls .doc.mpp
> > > respectively.
> > >
> > > Is there anything I can do to prevent this. The organisation I work
> > > for (and the organisation that builds LiveLink) are large and are
> > not
> > > going to change LiveLink to be more compatible with unison I'm
> > > afraid. What I'm really looking for is a unison option or hack that
> > > uploads the files with the correct extension.
> > >
> > > Thanks
> > >
> > > Adam
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > > <*> To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/unison-users/
> > >
> > > <*> Your email settings:
> > > Individual Email | Traditional
> > >
> > > <*> To change settings online go to:
> > > http://groups.yahoo.com/group/unison-users/join
> > > (Yahoo! ID required)
> > >
> > > <*> To change settings via email:
> > > mailto: unison-users-digest at yahoogroups.com
> > > mailto:unison-users-fullfeatured at yahoogroups.com
> > >
> > > <*> To unsubscribe from this group, send an email to:
> > > unison-users-unsubscribe at yahoogroups.com
> > >
> > > <*> Your use of Yahoo! Groups is subject to:
> > > http://docs.yahoo.com/info/terms/
> > >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070625/0384c05a/attachment.htm