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