"Sync" sometimes does not delete folders

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

"Sync" sometimes does not delete folders

Al Le
Hello,

Sometimes I get a wrong result when using the task "sync".

I try to synchronize a directory which is defined as a share on a
windows system (source) to a local directory (target), i.e. the local
dir should look like the share after the sync.

But sometimes, after the sync, I see that dirs which do not exist on the
share are not deleted on the local file system. Instead, just the files
in the dirs are deleted.

I still have not been able to track down when exactly it happens.
Sometimes it works as it should (i.e. the dir is deleted), but sometimes
it does not.

Has someone experienced this? What was the reason and the solution?

Thank you!
AL

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Sync" sometimes does not delete folders

Earl Hood
On Sat, Sep 17, 2016 at 5:05 PM, Al Le wrote:

> But sometimes, after the sync, I see that dirs which do not exist on the
> share are not deleted on the local file system. Instead, just the files in
> the dirs are deleted.
>
> I still have not been able to track down when exactly it happens.
Sometimes
> it works as it should (i.e. the dir is deleted), but sometimes it does
not.

Since you mentioned Windows, it is likely that the OS may still have a
"lock" on the directory, so any delete operation will fail.

Windows does not allow one to delete a file if there is a process that has
an open handle to it, and if a directory, an open handle to a file within
it. I believe there are race conditions within Windows on when a process
closes a handle and when Windows actually releases the handle. This could
be what is happening.  If you have AV software running, it could be a
factor.

Without examining the source of the sync task itself, unknown if operation
order can be modified to minimize the problem. I do not know if the sync
task checks if file deletions actually succeed. It is common for Java
programs to not check the return value of a delete operation (File#delete())
to verify it actually worked.

--ewh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Sync" sometimes does not delete folders

Al Le
> Windows does not allow one to delete a file if there is a process that has
> an open handle to it

Thank you for the hint! I'll check whether the dir is locked by a process.

> I do not know if the sync
> task checks if file deletions actually succeed. It is common for Java
> programs to not check the return value of a delete operation (File#delete())
> to verify it actually worked.

I see that the sync task does not check the return code. Here's an
excerpt from the source
(https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Sync.java,
line 246):

    log("Removing orphan directory: " + f, Project.MSG_DEBUG);
    f.delete();
    ++removedCount[0];

I saw a macro (macrodef) on the internet which mimics the sync behaviour
by combining copy and delete tasks, I'll give it a try.

AL

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Sync" sometimes does not delete folders

Al Le
In reply to this post by Al Le
Hello,

I could track down the reason for the problem. Now I'd need an advice from experts how to solve it :-)

When synchronizing the dirs, we'd like to preserve some files. These files have a certain local name. Hence we specify these files in the 'preserveintarget' clause.

The problem is that if a directory that should be deleted as a whole (because it does not exist in the source anymore) contains such a file, it does not get deleted (because it's still not empty).

How could I achieve that the non-existence of the dir in the source "wins" over the 'preserveintarget'?

Here's an example:

source dir structure: empty (i.e. no files or subdirs in it)

target dir structure:

aaa (dir)
   fileToPreserve.txt (file)

   
<project default="sync">

    <property name="from" value="C:\testFrom" />
    <property name="to" value="C:\testTo" />

    <target name="sync">
        <sync todir="${to}">
            <fileset dir="${from}"/>
            <preserveintarget>
                <include name="**/fileToPreserve.txt" />
            </preserveintarget>
        </sync>
    </target>

</project>


The desired result here would be that the dir 'aaa' is deleted in the target because the dir does not exist in the source.

What I observe is that the dir 'aaa' is not deleted because it contains a file to preserve. But this file should be ignored in my case because 'aaa' should be deleted as a whole. I.e. ant should not even look into aaa.

How can I achieve this?

Thanks!
AL

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Sync" sometimes does not delete folders

Dominique Devienne-2
On Mon, Oct 17, 2016 at 12:51 PM, Al Le <[hidden email]> wrote:

> When synchronizing the dirs, we'd like to preserve some files. These files
> have a certain local name. Hence we specify these files in the
> 'preserveintarget' clause.
> [...] What I observe is that the dir 'aaa' is not deleted because it
> contains a file to preserve. But this file should be ignored in my case
> because 'aaa' should be deleted as a whole. I.e. ant should not even look
> into aaa.
> How can I achieve this?
>

You can't.  <preserveintarget> "wins" indeed, by design, as the task is
currently implemented.
You'd need to add a (e.g.) "unlessAncestorDirIsRemoved" attribute on
<preserveintarget>
to "weaken"
<preserveintarget>, with associated logic of course.

Or you work around by copying/syncing your "preserved" files in to a 3rd
directory.
Sync as before, w/o the <preserveintarget> elements.
And "restore" those back, provided their directory still exists. I think
it's possible with a selector
and mapper to figure out of the "preserved" files should be restored (not
easy, but possible).

FWIW. --DD
Loading...