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