Re: Problem file
John Rose <[email protected]>
| Newsgroups | gmane.network.unison.general |
|---|---|
| Message-ID | <[email protected]> |
Dear Tõivo, Dear Alain, Several hours after the unison syncing involving the mystery file, a pdf file which I had just downloaded from the net (or its copy?) ended up in a file of the *same name *as the mystery file (based on doc) in the same directory as the mystery file had been in. It was recognized as pdf and could be opened in Ubuntu even without an extension. I did not try to copy it, but booted from Windows 11 and ran chkdsk whose only error message was that the index of that particular file was not correct. Then after some manipulations in Windows that I did not rigorously document (in principle limited to locating the file and perhaps opening it) the file disappeared (I did not in principle accidentally delete it since not in the trash), after which Windows chkdsk found no errors, and then the unison syncing in Ubuntu ran without any problems. This event is disconcerting as I have been using Ubuntu in dual boot with ntfs partitions since version 2011.4 LTS without anything like this happening before. A brief search of the web showed very little which could help me to resolve the problem. ntfs-3g is generally regarded as being reliable although much slower than native Windows (https://urldefense.com/v3/__https://unix.stackexchange.com/questions/754502/whats-the-difference-between-ntfs-3g-and-lowntfs-3g__;!!IBzWLUs!XSsvrxUbC6LRwf8NlBWuW-uixGfTxm0ZyvoeMrZOhOchBFtiEj2aZ_SIE8ZJADsksLtXNhhoet13e-h9g2a0PgAJoS4$ ); there are no readily available alternatives except lowntfs-3g which seems to be part of the same package as ntfs-3g (https://urldefense.com/v3/__https://linux.die.net/man/8/mount.lowntfs-3g__;!!IBzWLUs!XSsvrxUbC6LRwf8NlBWuW-uixGfTxm0ZyvoeMrZOhOchBFtiEj2aZ_SIE8ZJADsksLtXNhhoet13e-h9g2a08XDLr-I$ ). For the moment I propose only to i) make an independent (non-synced) back-up of my ntfs partition from Windows and ii) change the fstab parameters to go back more closely to the default values for Ubuntu (especially removing /*big_writes*/ which has been questioned in the past https://urldefense.com/v3/__https://unix.stackexchange.com/questions/536971/disadvantages-of-ntfs-3g-big-writes-mount-option__;!!IBzWLUs!XSsvrxUbC6LRwf8NlBWuW-uixGfTxm0ZyvoeMrZOhOchBFtiEj2aZ_SIE8ZJADsksLtXNhhoet13e-h9g2a0W_ZvfCQ$ ). So I conclude that Tõivo was right, no evidence that unison had anything to do with the problem, only helping to identify it. Will come back to you if any future in the future recurrence seems to implicate unison. Thanks and best regards, John Le 20/02/2024 à 22:51, Alain Mouette a écrit : > Can you copy those file manually? It already happened to me that the > file was corrupted and could not even be copied > > Alain > > On 2/20/24 14:16, Tõivo Leedjärv wrote: >> I don't see how this could be a Unison issue. You may certainly try >> deleting the ar* and fp* files (keep a backup) but it should not make >> any difference because this is not a corruption of any of those files. >> >> I am not familiar with ntfs-3g, so can't help in debugging, but I >> would start from that direction. I would recommend mounting the >> partition in Windows and letting it fix any issues with the file >> system. Then mount under Linux with a different NTFS driver (I don't >> know if any are available in Ubuntu) and see if the problem >> re-appears. I can't help with any of this but I'm sure there are >> people here who mount NTFS partitions under Linux and could help. >> >> On Tue, 20 Feb 2024 at 16:31, John Rose <[email protected]> wrote: >> >> Thanks, Tõivo. >> >> The concerned partition is mounted with the FSTAB entry: >> >> /*UUID=0D350FB60D350FB6 /media/john/Data ntfs-3g >> defaults,windows_names,big_writes,locale=fr_FR.utf8,uid=1000,gid=1000,fmask=0002,dmask=0002,x-gvfs-show >> 0 0*/ >> >> windows_names limits the characters in filenames to those >> accepted by Windows. I have thousands of files in this partition >> and dozens sync without problem, only one word-processing file >> (LibreOffice Writer) gives difficulties, and I can for the moment >> see nothing in either the filename, nor the permissions nor the >> content which could cause it. I prefer saving all my >> word-processing files with the doc extension to ensure >> compatibility for my Windows-user friends (certainly not docx >> which should never have been approved as an international >> standard competing commercially with open-source odt). >> >> Four ar.... files and four fp.... files were generated/modified >> by unison during this syncing, and one or more are obviously >> corrupted now (since the mysterious file shows up in unison even >> though no longer physically present. Can/should I delete some or >> all of these files and redo the archives to see the problem is >> solved? >> >> Best regards, >> >> John >> >> Le 20/02/2024 à 12:01, Tõivo Leedjärv a écrit : >>> Hi John, >>> >>> This is most likely caused by whatever filesystem driver you're >>> using to mount NTFS. >>> >>> Unison does not create files like this. The error "Erreur >>> d'entrée/sortie" (which I'm assuming is EIO) also directly >>> points to the filesystem driver/FUSE/kernel/disk, not a problem >>> with Unison. >>> >>> I'm sorry, I can't be more helpful as I don't know much about >>> mounting NTFS under Linux. >>> >>> >>> On Tue, 20 Feb 2024 at 11:42, John Rose <[email protected]> wrote: >>> >>> Hello, >>> >>> I am using unison 2.53 under Ubuntu 22.04 LTS. Everything >>> syncs OK except one ntfs doc file which gives the error >>> below (syncing with an ntfs partition on an external SSD). >>> There was one unison entry for the file /Requests for >>> articles.doc/ which synced fine left to right and another >>> file with /.ntfs-3g-0000000001/ added at the end of the >>> filename with an X for skipping. I had this same problem >>> with this same file a couple of days ago. I at that time >>> created an new document and pasted in the content, then >>> deleted the original document and it synced fine, but the X >>> for skipping has now returned for the same file with >>> /.ntfs-3g-0000000001/ added at the end of the filename. I >>> rebooted and get the same error for this same file. Both of >>> the files (the original on both roots and the new one on the >>> external SSD) open normally, and have the normal permissions >>> (read-write for me and my group, read for others). >>> >>> The original file /Requests for articles.doc/ is thus fine >>> on both roots and syncs, but on the external SSD another >>> file was apparently been added (by unison?) called /Requests >>> for articles.doc.ntfs-3g-0000000001/. I deleted this file >>> and I still get it in the sync list with an X (even though >>> it is no longer present in either root). >>> >>> So it looks to me that the archives file has been corrupted. >>> Why is this happening and what to do? >>> >>> Thanks and best regards, >>> >>> John >>> >>> -- >>> ************ >>> >>> John B. Rose >>> 1 Bis rue des Châtre-Sacs >>> 92310 Sèvres, France >>> >>> Email:[email protected] >>> >>> -- >>> To unsubscribe from this group and stop receiving emails >>> from it, send an email to >>> [email protected]. >>> >> -- >> ************ >> >> John B. Rose >> 1 Bis rue des Châtre-Sacs >> 92310 Sèvres, France >> >> Email:[email protected] >> >> -- >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> >> -- >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. > > -- > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. -- ************ John B. Rose 1 Bis rue des Châtre-Sacs 92310 Sèvres, France Email:[email protected] -- To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].