adding files to mercurial repository fails on ntfs

[Raf Geens]

Binary package hint: mercurial

Ubuntu 8.04
mercurial 0.9.5-3

When adding a file to a new or existing mercurial repository that's located on a writable NTFS volume, I get the following error, after which the file isn't added:

Exception exceptions.OSError: (1, 'Operation not permitted', '/media/windows/test/.hg/.dirstate-_XPYRk') in <bound method lock.__del__ of <mercurial.lock.lock object at 0x8350e6c>> ignored

The /proc/mounts entry for the file system is: /dev/sdc1 /media/windows fuseblk rw,nosuid,nodev,noatime,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0

It occurs on another NTFS disk as well. I have no problems on my ext3 filesystem, or when using the Windows version of Mercurial. I've attached the steps I did.

[Savvas Radevic (medigeek)]

Hi, can you test the if the bug can be reproduced?

$ apt-cache policy mercurial
mercurial:
  Installed: 1.0.1-5.1
  Candidate: 1.0.1-5.1
  Version table:
 *** 1.0.1-5.1 0
        500 http://de.archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

1.0.1-5.1~hardy1 is available in hardy backports as well! More info: https://help.ubuntu.com/community/UbuntuBackports

You can click on your architecture (32-bit=i386, 64-bit=amd64) below to install your package:
http://packages.ubuntu.com/hardy-backports/devel/mercurial
http://packages.ubuntu.com/hardy-backports/devel/mercurial-common

[Savvas Radevic (medigeek)]

Note: this bug might be connected to bug #190725
https://bugs.launchpad.net/bzr/+bug/190725
 "[Hg/Mercurial has the same problem, btw.]"

[Raf Geens (rafgeens)]

That pc is currently having its motherboard replaced, but I'll take a look when that's done.

[Raf Geens (rafgeens)]

The bug still reproduces in version 1.0.1-5.1 on Intrepid.

[Savvas Radevic (medigeek)]

Thanks for testing it, setting back to New.

Can you post the output of these commands:

cat /etc/fstab
mount
sudo fdisk -l
ls -l /dev/disk/by-uuid/

[Raf Geens (rafgeens)]

Here you go, this is from a fresh Intrepid install. The /dev/sdc1 in the output isn't the same as in the original report, since my disk configuration changed in the meanwhile. There's also something odd going on with the ordering of the disks, but that doesn't seem related to this bug.

[Savvas Radevic (medigeek)]

Execute this:
id -u

Remember the number it outputs (required below).

Then try this:
gksu gedit /etc/fstab

find the line:

# /dev/sdb1
UUID=7238946C389430D9 /media/windows ntfs
defaults,umask=007,gid=46 0 1

Replace it with:

# /dev/sdb1
UUID=7238946C389430D9 /media/windows ntfs
defaults,umask=007,gid=46,uid=1000 0 1

..where "1000" is the number you got with "id -u" command above. Now
save and close the text editor.
Reboot the machine and try again.

[Raf Geens (rafgeens)]

That works :-)

[Savvas Radevic (medigeek)]

Unfortunately this is due to permission restrictions presented in ntfs filesystems, which are different from other filesystems, such as ext3.

I don't expect anyone to fix this, but I won't close the bug either, let's leave it to the bug triagers and/or developers to decide.

[Scott Kitterman (kitterman)]

Not a mercurial bug then.

[Szabolcs Szakacsits (szaka)]

The driver works as expected (Operation not permitted). Remove the default_permissions option then it should work. Please see more detail about permission handling in the NTFS-3G manual ('Access Handling and Security' section): http://ntfs-3g.org/manual.html