[Ardour-Dev] Trouble with imported files

[Fons Adriaensen]

On Sun, Mar 08, 2009 at 09:17:42PM -0400, Paul Davis wrote:

> The goal was to avoid creating havoc through accidental deletion or movement
> of files external to the session. The user could do this and the session
> would continue to function just fine.

I know, but see below.
 
> quite a specialized use case, then.

Something you could find in any production
environment that has a number of similar
studios that have to be exchangeable.
 
> sounds like your using the wrong tool to make the copy. what are you using?
> i am fairly sure that tar(1) will preserve the links *as links*, and not
> pretend that there are actually two copies.

There is no difference between two hard links. 
Tar can ignore soft links, as can cp and rsync,
but a hard link is the same thing as the original.
None of them, afaik, keeps a list of files already
copied to detect duplicates. It would fail anyway
if the copies are not made using a single command.

> what filesystem are you using on the USB sticks?

ext2

> > So what was intended to be shared by many
> > sessions get assimilated, Borg style, by
> > each of then when that session is moved.
> > Resistance seems to be futile.
> 
> but the "assimilation" happened at the copy step, no? before the copy, there
> was one instance of the file with two hard links. after the copy, on the
> destination filesystem, there are two copies of the file. why is this
> ardour's fault?

Because ardour made the hard link, while it could
as well have done the same thing as when the files
were on different mount points. And it did that
after the user had

- disabled 'always copy' in the options menu
- disabled 'copy files' in the import dialog
  each and every time he/she used it.

I think the user's intentions should be clear
after he/she has gone through these steps which
seem clearly designed to discourage the use of
external files.

> we are not trying to subvert the user's intention. we had many early losers
> who careless/accidental actions would break sessions. using a hard link
> fixed this.

These losers had gone through the steps listed
above. This does not happen by accident, rather
the inverse - it's all to easy to forget disabling
copies. The rest is the consequence of their very
deliberate choice.

The protection you try to offer fails if the files
are not on the same partition. You can't depend on
it.
 
> now, it has to be said that since we now handle missing audio files in a
> more-or-less reasonable fashion, its not so clear that this FS-dependent
> approach is really the best one anymore. it does still have some nice
> properties, but i can see an argument for its removal.

The main argument is that this depends on a condition
that the user is normally not aware of. Try explaining
mount points to the average musician, and why it should
make a difference on which partition a file is stored.

> removing it means commenting out about 3 lines of code.

Then please, do remove it.

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Be quiet, Master Land; and you, Professor,
will you be so good as to listen to me ?