Re: "Sync" sometimes does not delete folders

[Dominique Devienne]

On Mon, Oct 17, 2016 at 12:51 PM, Al Le  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.   "wins" indeed, by design, as the task is
currently implemented.
You'd need to add a (e.g.) "unlessAncestorDirIsRemoved" attribute on

to "weaken"
, 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  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

Re: "Sync" sometimes does not delete folders

[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)

   

















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: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org

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: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org

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

"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: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org