Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000441FlexRAID Transparent RAID[All Projects] Generalpublic2017-01-12 15:512017-01-14 21:14
Assigned ToBrahim 
PlatformWindowsOSWindows Server 2012 R2OS Version
Summary0000441: Mercurial still not working correctly (Permission denied)
DescriptionWhen dealing with bigger Mercurial projects (a few hundred files), I receive error messages during "hg strip" and "hg recover":
   >> hg strip --verbose --nobackup 39
   > ...
   > transaction abort!
   > failed to truncate data/classes/local/UserIntern.class.php.i
   > rollback failed - please run hg recover
   > abort: Permission denied

   >> hg recover
   > rolling back interrupted transaction
   > failed to truncate data/classes/mysql/MySQL.class.php.i
   > abort: Permission denied

The log shows warnings like this:
[2017-01-12 16:14:15.139252][4048] [WARN]:[OnSetEndOfFile] SetLengthByHandle: error=5, msg=Error code=5 - Message=Input/output error
            \ft\.hg\store\data\classes\local\_user_intern.class.php.i -> [HGST1 (Data)]::[Partition1]\ft\.hg\store\data\classes\local\_user_intern.class.php.i
Additional InformationAlthough I always get an error when doing this with larger projects, it seems to different files actually causing trouble. Just cloning or pull/push to add changesets still works fine and also survived "hg verify" in any case so far.

I added logs (TRACE) for both errors:
UserIntern.class.php.i -> userintern.log (line 14643)
MySQL.class.php.i -> mysql.log (line 3477)
You also just search the files for "code=5"

I'm using the build with the latest Mercurial fix from Jan 9th (

Client OS (running Mercurial): Win 8.1 Prof x64
TagsNo tags attached.
tRAID Version 1.0
Attached Fileslog file icon userintern.log [^] (1,896,686 bytes) 2017-01-12 15:51
log file icon mysql.log [^] (319,166 bytes) 2017-01-12 15:51
zip file icon [^] (972,105 bytes) 2017-01-12 22:30

- Relationships

-  Notes
adridolf (reporter)
2017-01-12 16:39

In case you're not familiar with Mercurial: The difference of the "hg strip" command in contrast to the tasks I tested earlier is that the strip command deletes changesets and the underlying data, while "hg clone" and "hg push/pull" commands are mostly modifying or adding files.
Brahim (manager)
2017-01-12 20:27
edited on: 2017-01-12 20:28

The behavior seems correct. Those files are being opened with only read permission. So, a write attempt should fail with permission denied.

Below is a build with extra logs to fully analyze the opening file permissions.
Note that this build also has the URB reverted back to regular mode.

adridolf (reporter)
2017-01-12 20:31

Can't find the build (am I too quick?)

Switching back to regular mode is a good idea after all.
Brahim (manager)
2017-01-12 21:19
edited on: 2017-01-12 21:21

The link is posted above your post. Or, maybe it is because I made it private.
Just made it public.

adridolf (reporter)
2017-01-12 22:29
edited on: 2017-01-12 22:34

Quite strange: The error only occurs when I'm accessing the repository over a slow connection (1-4 Mbytes per sec.). When I do the same accessing the network share with Gigabit LAN, there is no error.

For testing, I did both strip and recover over slow connection (to log the errors), then performed recover with Gigabit LAN locally without any errors (in both cases using the same UNC path). To find the error messages, again search the log files for "code=5".

Logs are in

% hg strip --verbose --nobackup 36 [SLOW -> strip.log]
20 files updated, 0 files merged, 8 files removed, 0 files unresolved
transaction abort!
failed to truncate data/classes/local/BbrConvert.class.php.i
rollback failed - please run hg recover
abort: Permission denied
[command returned code 255 Thu Jan 12 23:15:41 2017]

% hg recover [SLOW -> recover.log]
rolling back interrupted transaction
failed to truncate data/classes/local/TemplateFTpublic.class.php.i
abort: Permission denied
[command returned code 255 Thu Jan 12 23:17:39 2017]

% hg recover [GIGABIT -> working.log]
rolling back interrupted transaction
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
836 files, 36 changesets, 1258 total revisions
[command completed successfully Thu Jan 12 23:20:25 2017]

This is reproducible, so I can alternately corrupt and repair the repository by just switching the machines.

Brahim (manager)
2017-01-13 02:36

The behavior is correct.

In all instances of the failure, the files were opened with only read permissions ([SPECIFIC_RIGHTS_ALL, FILE_READ_DATA, FILE_LIST_DIRECTORY, FILE_READ_ATTRIBUTES]).

The same operation succeeded for when the files were opened with write permissions.
Why the program behaves differently between connections is what you will need to investigate.

- Issue History
Date Modified Username Field Change
2017-01-12 15:51 adridolf New Issue
2017-01-12 15:51 adridolf File Added: userintern.log
2017-01-12 15:51 adridolf File Added: mysql.log
2017-01-12 16:39 adridolf Note Added: 0001681
2017-01-12 20:27 Brahim Note Added: 0001682
2017-01-12 20:27 Brahim Assigned To => Brahim
2017-01-12 20:27 Brahim Status new => feedback
2017-01-12 20:28 Brahim Note Edited: 0001682 View Revisions
2017-01-12 20:31 adridolf Note Added: 0001684
2017-01-12 20:31 adridolf Status feedback => assigned
2017-01-12 21:19 Brahim Note Added: 0001685
2017-01-12 21:21 Brahim Note Edited: 0001685 View Revisions
2017-01-12 21:21 Brahim Status assigned => feedback
2017-01-12 22:29 adridolf Note Added: 0001686
2017-01-12 22:29 adridolf Status feedback => assigned
2017-01-12 22:30 adridolf File Added:
2017-01-12 22:31 adridolf Note Edited: 0001686 View Revisions
2017-01-12 22:32 adridolf Note Edited: 0001686 View Revisions
2017-01-12 22:34 adridolf Note Edited: 0001686 View Revisions
2017-01-13 02:36 Brahim Note Added: 0001689
2017-01-13 02:36 Brahim Status assigned => feedback
2017-01-14 21:14 Brahim Status feedback => resolved
2017-01-14 21:14 Brahim Resolution open => fixed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker