Szabolcs Szakacsits wrote, on 04/18/2009 08:08 PM:
> 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
[~]% ntfs-3g --help
ntfs-3g 1.2506 external FUSE 27 - Third Generation NTFS Driver
Copyright (C) 2006-2008 Szabolcs Szakacsits
Copyright (C) 2005-2007 Yura Pakhuchiy
Usage: ntfs-3g <device|image_file> <mount_point> [-o option[,...]]
Options: ro (read-only mount), force, remove_hiberfile, locale=,
uid=, gid=, umask=, fmask=, dmask=, streams_interface=,
syncio.
Please see the details in the manual.
Example: ntfs-3g /dev/sda1 /mnt/win -o force
Ntfs-3g news, support and information: http://ntfs-3g.org
I am getting this from hardy-backports, so I am not running a version
quite that old.
> 2. Integrated FUSE (see 'ntfs-3g --help' output). We promptly port, test
> and release FUSE CVS fixes in NTFS-3G releases.
I gather I am still using the non-integrated FUSE.
> 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.
% uname -a
Linux alohomora 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009
i686 GNU/Linux
>From dpkg I see:
ii libfuse2 2.7.2-1ubuntu2 Filesystem in USErspace library
> 4. CVS version. You included this one. I suppose you use the same CVS
> version with ext3 too.
Yes, there was no change in cvs.
> 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.
As I recall these are in /var/log/daemon.log, but I did not check for
log messages during the time of these errors. Sorry.
>> 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.
This is plausible.
>> 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.
I will keep an eye on updates to my version of NTFS-3G and give it
another try.
Thanks for your response,
Ted
------------------------------------------------------------------------------
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
