Access denied on git repo files

[AteCoder]

I am now on version 11.15 (donation edition). This report was generated with version 11.14. The issue is still present in version 11.15.

I am seeing access deny errors with FFS.

I attached a series of screen shots that I hope show how this manifests itself when synching with Free File Sync (FFS) and how synching succeeds on subsequent attempts without making any manual changes to unblock the files other than trying to sync again. Consequently, when synching GIT folders, every sync needs to be ran twice.

The first screenshot shows the first FFS message. A series of subsequent screenshots show how this is reported as the sync process proceeds. The last couple of images show what happens after I click Synchronize again where the files do get synched. More often, though, the second sync succeeds only after restarting FFS.

[xCSxXenon]

Pictures so others don't have to download:

AccessDeniedScreenShot1.png (9.62 KiB) Viewed 2467 times

AccessDeniedScreenShot2.png (35.72 KiB) Viewed 2467 times

AccessDeniedScreenShot3.png (117.33 KiB) Viewed 2467 times

AccessDeniedScreenShot4.png (13.51 KiB) Viewed 2467 times

AccessDeniedScreenShot5.png (97.06 KiB) Viewed 2467 times

[Zenju]

Pictures so others don't have to download:

Wow, thanks! :)

[xCSxXenon]

Of course! Now for the issue, I have no idea why that's happening.
I wonder if it's a network timeout that gets re-established by restarting FFS.

[AteCoder]

I am not seeing any Windows events that I can relate to this behavior.

[xCSxXenon]

What if you try syncing different data to that same network location? That could tell us if there is an issue with the git repo files or the network access itself

[AteCoder]

Sure. I can do that. What do u suggest?

For example, say I have committed some files to the repo. Now I have some data to sync, which include, among others, some files from the .git\objects folder that cause the Access Denied failure. When I sync, all files sync, including copy and delete, except for the commit-graph (for update) and the .idx, and .pack (for deletion).

I can try to sync some random folders first not including the .git\objects folder and then sync the rest including the objects folder.

Will this give us the info you are looking for?

[xCSxXenon]

That can help. I wonder if those three files are just in use longer after a commit. How long after the commit are you waiting to run the sync?

[AteCoder]

I too was wondering about the timing issue and tried to wait a bit before syncing. Waiting did not seem to make a difference. I also ran the successful second attempt to commit almost immediately, which seems to suggest looking at FFS rather than GIT. I am still not fully committed (pan not intended) either way.

[AteCoder]

I synced as follows:
(1) commit;
(2) waited about 30 minutes;
(3) ran a sync on a subfolder (e.g., trash) of the main folder (c:\my) to test a sync using the same top folder; success;
(4) ran a second sync on the same folder for deleting some files on the target folder; success;
(5) ran a sync of c:\my; got an access denied message on the expected files (idx/.pack)
(6) ran another sync right away; the 'denied' files were copied/deleted.

[xCSxXenon]

Run a system log and we should be able to find out what has a lock on those files.
https://freefilesync.org/faq.php#trace

[AteCoder]

zipped file too big to upload. I posted it on Google Drive; https://drive.google.com/file/d/1TQTFT1-wlyITJ2U-J4DALosou_oDjSIl/view?usp=sharing

[xCSxXenon]

At "12/22/2021 1:06:01.0758870 PM" there is a string of events relating to the 'commit-graph' file. I see a few ACCESS_DENIED, BUFFER OVERFLOW, and other errors. Zenju is way more knowledgeable with this, maybe he can chime in. I searched for "My\lib" and didn't find it, so I'm assuming that was suring a sync of a different repo?

[AteCoder]

search for my\ the repo is in my\solution. same issue. but focusing on a single repo hopefully making this easier. thanks you!

[AteCoder]

- I do not see this issue when synching onto a Synology NAS.
- I still see this issue when syncing from a VMWARE Workstation to the host (Windows 10).
- I am fairly confident that the issue, which I reported on December 21, did not exist before October 2021.
- So, if this issue is due to a Workstation change, it could be in 16.2.0 (released October 14, 21) or 16.2.1 (released November 09, 21)

I have an older machine running an older version of VMWare workstation, which I can use to test this hypothesis. It will take some fiddling, which I am prepared to try.

[AteCoder]

The files that fail to synchronize are marked as Read Only on the source side. Once synchronized to a new target, these files still are marked read only. On a sync that attempts to delete such files, FFS reports 'Access Denied'. After closing FFS, opening it and selecting 'Show in Explorer' a file that failed to sync and was previously marked as read only is no longer Read Only, which explains how FFS is able to sync the file.

It is interesting, though, that FFS needs to be closed and then opened for the sync to work on the second trial.

Also, on a second attempt, I open the folder where the read only file is located. Before 'Access Denied' the file was marked as read only. I ran the sync, which failed and looked at the file and it was no longer Read Only. thereafter the sync ran without having to toggle (close and open) FFS.

I hope this helps figuring out a solution to this issue.

[xCSxXenon]

Great work and interesting results. Do you have the option enabled to preserve permissions?

[AteCoder]

I looked at Options, Sync Options (F8), and web Manual -- could you please point me to where I can see this 'preserve permissions' option?

[xCSxXenon]

Tools -> Options
"Copy DACL.....,Group"

[AteCoder]

Tools -> Options show:
[x] file-safe file copy
[ ] Copy locked files
[ ] Copy DACL, SACL, Owner Group

... looking at the last sync read-only is checked on the pack-... file that causes access-denied.

So it looks like the permissions do get copied, right?

[xCSxXenon]

Correct, permissions aren't being copied. Although "read-only" may not be a permission but it could be an attribute.

[AteCoder]

Of course, an attribute that gets copied. Makes sense. So FFS has a file to delete. It has to flip it's RO attribute and then delete it. Does the log show what is the reason for denying access to the file? Is it the RO attribute?

[AteCoder]

Unchecking the Read-Only attributes on these files allows FFS to sync without failures when syncing from the VM client to the host.

Note that the read only attribute on the NAS, to which syncing proceeded without failures is also checked.

So, somehow, with the change of VM (possibly 12.0 to 12.1), FFS fails when synching to the host most likely seeing the RO attribute as checked when in fact it was successfully unchecked by FFS. Moreover, somehow FFS sees the correct status of the attribute if the host folder is open in the client, which might give you guys the clue to the issue.

[AteCoder]

VMWare workstation 16.2.3 no longer has this issue.

Thank you for your support.