Unexpected Error Message While Copying Hardlinked Files

[SvA]

I got an unexpected error message while trying to copy files to a backup directory, which contains files hardlinked to the source with the same name in both dirs, e.g src\file.ext and dest\file.exe.

Copying files from src to dest gives error message:

Name: src\file.ext

Error: (32) Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

[The process cannot access the file because it is locked by another process.]

The 'other' process seems to be the very same instance of Servant Salamander.

I know that hardlinks are not yet propperly supported by Servant Salamander, but I thought I would report this, for Altap's developper to note when they set out to implement hardlink support (or even before).

[Petr Solin]

It seems that you are trying to copy the file to itself, is it right?

We probably should ignore such copy operations (they have no sence) or better we should show you "you are trying to copy the file to itself" error message, or do you expect some more sophisticated support?

[SvA]

It seems that you are trying to copy the file to itself, is it right?

Yes and no! I do not have any junctions but hardlinks on files. Therefore the copy was to a different directory entry, but the same (identical) file content.

We probably should ignore such copy operations (they have no sence)

I don't agree. I was expecting to get the dialog where I was asked as to whether I wanted to overwrite the destination. My intention was to ignore all existing files anyway. If a had agreed to overwrite, however, I would have expected to get the same result as when the destination file was deleted first, then the source file copied to the destination.

or better we should show you "you are trying to copy the file to itself" error message,

As explained above, this was not the case. Even though the two files have identical data, located at identical disk clusters, deleting the destination file would not free the occupied disk space, thus not deleting the source file as it were, if it was the same file. Therefore a copy was possible without any difficulty.

or do you expect some more sophisticated support?

What a question! of course I am. I always expect everything to be perfect. I am forgiving, though, if matters are fairly complicated and not vitaly important as in cases like this, and furthermore if I find ambition to solve problems and improve a software as you do.

[Petr Solin]

OK, I understand the problem. There are two variants for overwrite operation: open target file and write to it (links are not broken, currently used in Explorer and Salamander), or delete target file, create new and write to it (link is deleted - it's what you suggest).

I checked how this operation is solved in Explorer and Total Commander (TC). Explorer displays the same error as Salamander. TC has its own solution (I expect it's bug): links are not broken, but it fills the target (and also source) file with zeros (file length is not changed), so the file is lost.

I was surprised that Windows XP does not handle directory listings with hard links properly - when I change the file, the linked file seems to be unchanged until I open it in viewer (or any other operation).

We will support hard links in some future version, I hope it will be also better supported in Windows.

[SvA]

Well, as I said, this matter if fairly complicated and a considerable ammount of thought should be put into it. (Most likely the unix people and designers of other file and operating systems which have used hardlinks for ages already have.) Most likely, the correct answer is: It depends... (on the purpose and goal of the copy operation).

But as I said, my intention was not to copy the file anyway. I was expecting to get an overwrite warning/confirmation (just as if the files were not linked to each other or to any other file). My intention was to only copy nonexisting files. This behaviour was (would be) independent on the copy method used later on, should need for copying arise.

There are two variants for overwrite operation: open target file and write to it (links are not broken, currently used in Explorer and Salamander),

This is probably what I generaly would expect if the destination file is not linked to the source file, but to any other. In other situations, I would expect to get a completely independent file (i.e delete then create new).

or delete target file, create new and write to it (link is deleted - it's what you suggest).

This is probably what I would expect if source and target files are linked to each other. However I also might expect to get an independent copy in the source and the original file (with other, external hardlinks still pointing to that copy's content). This realy depends on the purpose of the copy and how I intend to use the source or destination file after that.

I checked how this operation is solved in Explorer and Total Commander (TC).

It's ok to check, what others have done. However, hardlinks are fairly new to the Windows world and things are not established yet. Therefore better look where more experience flowed into the design and think through it yourself.

I was surprised that Windows XP does not handle directory listings with hard links properly - when I change the file, the linked file seems to be unchanged until I open it in viewer (or any other operation).

I am not at all. Windows can easly test whether a hardlink exists on a file, but there is no way for Windows to find out which other directory entry points to that same file data other than by scanning the directory tree and querying each file's ID-Nr (or whatever the analogon to unix's i-node number is called in NTFS). Windows (or explorer) could do a check on enumerating a directory's content, but that was not very effective to do.