Hi Ted,
On Fri, 17 Apr 2009, Ted Anderson wrote:
> I am sorry to have to make this not-very-useful bug report.
That's okey.
> For a few years now, I have been using NTFS-3G to provide Linux access to
> Windows files allowing me to easily switch back to Windows. This has
> been quite trouble free, except for one important exception. One of the
> filesystems I access from Linux via NTFS-3G holds my local CVS checkout
> sandbox. What I have seen is intermittent problems with the cvs update
> command (cvs version 1.12.13) when run on Linux (Ubuntu 8.04).
These are the most important things:
1. Latest NTFS-3G driver. Ubuntu 8.04 has 1.2216 which is 14 months
old. We may already fixed the problem very long ago:
http://ntfs-3g.org/releases.html
2. Integrated FUSE (see 'ntfs-3g --help' output). We promptly port, test
and release FUSE CVS fixes in NTFS-3G releases.
3. Kernel version or the latest FUSE kernel module from the 2.7.4 FUSE
package. 2.6.26 or later kernels should be ok. Earlier ones missed
sometimes attribute updates which could cause weird problems.
4. CVS version. You included this one. I suppose you use the same CVS
version with ext3 too.
It would be nice to know if your problem is reproducible with the latest
NTFS-3G version using integrated FUSE and if so then how.
I suppose you didn't have any ntfs-3g error messages in the log files under
/var /log.
> The symptoms are that the source file is properly updated, but the
> CVS/Entries files is not updated. The effect is that while the source
> code is up to date, the checked out version still refers to the
> pre-update version. After a successful update "cvs status" should
> report that the Working and Repository versions are the same. But
> intermittently I find that some or all of the updated files still show
> the old Working revision number. This failure is silent in the sense
> that "cvs update" does not complain or generate a non-zero exit status.
>
> Sometimes I can just reissue the cvs update command and it succeeds.
> Other times, I can run the command over and over and it persistently
> fails to update the Working revision (usually, it is will work the next
> day or on the next update). I have found it more often fails
> persistently when updating an explicit list of files. Updates of
> directories are more often successful.
It could be related to one of the timestamp update problems we found and
solved last year.
> I have tried debugging this by capturing the strace output, but cvs is
> sufficiently idiosyncratic that I have not been able to understand from
> this how a working and non-working version differ in their system call
> level behavior.
If it's timestamp related then it's fairly difficult to find the root
(about impossible).
> As a test, I recently copied my source tree to an ext3 partition and the
> problem completely disappeared. I've been running this way for several
> weeks have have not seen a single problem with cvs update. This makes a
> pretty strong case that the problem is directly related to using NTFS-3G
> to store the checked-out files and CVS metadata files.
>
> I realize this report doesn't give NTFS-3G developers much to go on.
> However, I am hoping that other users will have noticed similar behavior
> and have additional useful details or anecdotes to report.
Recently we didn't receive such bug reports.
Regards,
Szaka
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
