File problems in Pharo 8

Hi,

In Pharo 8 I have troubles because I get an error each time I try to
do an action calling a #deleteAll.

I think the problem might have been introduced by the changes on Files
that were done to introduce FIleAttributes.

I don't have much knowledge on this area and this is a little blocking
for me because when the problem triggers I cannot commit my changes
with Iceberg since it needs to delete folders.

Bug report: https://github.com/pharo-project/pharo/issues/2495

--
Cyril Ferlicot
https://ferlicot.fr

On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant <[hidden email]> wrote:
I can commit with this vm. Thank you.

I have the impression that the commit takes longer now but I don't
have any bench. (maybe it's just my imagination).

>
> Cheers,
> Alistair
> (on phone)
>
>>


--
Cyril Ferlicot
https://ferlicot.fr

Hi Cyril,

On Tue, 12 Feb 2019 at 11:57, Cyril Ferlicot <[hidden email]> wrote:
I'm glad you're able to commit now. :-)

> I have the impression that the commit takes longer now but I don't
> have any bench. (maybe it's just my imagination).

A few comments on the performance:

I haven't done a performance comparison for a while, and there have been
a few changes in the plugin, so I'll keep it qualitative for now and try
and run some more tests soon.

FileReference>>exists should be significantly faster than before.  It
used to retrieve all the file attributes (an array of values, mostly
integers and booleans).  Now it just returns a boolean.

Retrieving individual file attributes should also be faster.  E.g.
FileReference>>modificationTime also retrieved all file attributes and
threw away everything except the desired attribute.  Now it answers just
the requested attribute.

Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit
slower because more information is being retrieved than previously.

FileReference>>exists gets called a lot.  So do requests for individual
file attributes.  So my perception was that overall the system would
probably be a bit faster than previously.

However any application that iterates over a large number of files could
well be slower because the Guide / Visitor system retrieves entries.

Do you know how many files are being deleted when the system feels
slower?

It would be straightforward to modify the directory iteration primitives
to only answer the file name instead of all attributes.  I'll have a
look and see how easy it would be to modify the Guide / Visitor objects
to retrieve only file names instead of entire entries.

Cheers,
Alistair

Le 12/02/2019 à 18:56, Alistair Grant a écrit : Thank you for the detailed explanation!

> Do you know how many files are being deleted when the system feels
> slower?

I was committing in Iceberg that is a Filetree repository. My change
impacted multiple package thus I would say it should be around 2500
files and 500 folders.

>
> It would be straightforward to modify the directory iteration primitives
> to only answer the file name instead of all attributes.  I'll have a
> look and see how easy it would be to modify the Guide / Visitor objects
> to retrieve only file names instead of entire entries.
>

So if possible it would make file copy/deletion even faster than before
IIUC? That would be really great!

> Cheers,
> Alistair
>


--
Cyril Ferlicot
https://ferlicot.fr

Hi Cyril,

On Tue, 12 Feb 2019 at 19:41, Cyril Ferlicot D.
<[hidden email]> wrote: I wrote a class to measure the time taken by the Visitor / Guide -
it's basically the same as the DeleteVisitor but just counts the
number of files visited.  Running this on a directory that contains
82331 files including 10169 directories.   My 6 year old Dell XPS 13
(i7, SSD, 8G RAM) gives the following average times:

Pharo 7: 3.7 seconds
Pharo 8: 2.6 seconds

I've attached the class below.

> > It would be straightforward to modify the directory iteration primitives
> > to only answer the file name instead of all attributes.  I'll have a
> > look and see how easy it would be to modify the Guide / Visitor objects
> > to retrieve only file names instead of entire entries.
> >
>
> So if possible it would make file copy/deletion even faster than before
> IIUC? That would be really great!

The Guide / Visitor framework uses file attributes to navigate the
tree, so retrieving only file names wouldn't be useful.

But I did notice that the entries weren't being initialised properly,
so after fixing that bug the average run time for Pharo 8 drops:

Pharo 8: 1.7 seconds

I'll submit a PR with this fix.

I also realised I inadvertently changed the behaviour of DeleteVisitor
slightly.  In Pharo 7 the Visitor will descend in to a symbolic link
that points to a directory, in Pharo 8 it doesn't.  This prevents the
system from entering an infinite loop if the symbolic link points to
the directory containing the link, but means that the set of files
visited may be different.  Pharo 7 may visit additional files that are
currently skipped by Pharo 8, or it may visit some multiple times.
I'll raise this as a separate discussion as I'm not sure that simply
reverting to the old behaviour is a good idea.

Cheers,
Alistair

Alistair Grant wrote
> I… changed the behaviour of DeleteVisitor
> slightly.  In Pharo 7 the Visitor will descend in to a symbolic link
> that points to a directory, in Pharo 8 it doesn't.

Thank goodness someone finally fixed that! IMHO the old behavior was
extremely dangerous and I greatly limited my use of #deleteAll for that
reason.

'/path/to/aFolder' deleteAll

where
- aFolder
  - aSymbolicLinkTo~

No problem, we all have backups, right?... right?



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html