Catch that error, and copy-and-delete.

I suggest this is typical EAFP (Easier to ask for forgiveness than permission) coding style from Zen of Python http://docs.python.org//glossary.html#term-eafp http://docs.python.org//glossary.html#term-eafp I'm very curious to know how Haskellers think and do about it? Is there something close to Zen of Haskell?

On 2021-04-15, at 13:08, Donn Cave wrote:

...

...

I don't know how to detect whether two filepaths are in the same filesystem.

Yes you do!

...

...

If I use System.Directory.renameFile and the final location is in another filesystem, I'll get an error "renameFile:renamePath:rename: unsupported operation (Invalid cross-device link)".

And it follows that if you get no error, the two filepaths are in the same filesystem

...

...

What's the best way to move the file if possible but copy-and-delete if necessary?

Catch that error, and copy-and-delete.

Donn _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

quoth YueCompl

...

Catch that error, and copy-and-delete.

I suggest this is typical EAFP (Easier to ask for forgiveness than permission) coding style from Zen of Python http://docs.python.org//glossary.html#term-eafp http://docs.python.org//glossary.html#term-eafp

I'm very curious to know how Haskellers think and do about it?

Is there something close to Zen of Haskell?

For another example, I quote from my man page for access(2), which can be used to determine if the caller has the necessary privilege etc. - " The result of access() should not be used to make an actual access control decision, since its response, even if correct at the moment it is formed, may be outdated at the time you act on it. access() results should only be used to pre-flight, such as when configuring user interface elements or for optimization purposes. The actual access control decision should be made by attempting to execute the relevant system call while holding the applicable credentials, and properly handling any resulting errors; and this must be done even though access() may have predicted success." That particular consideration doesn't apply so much to this case, that I can see anyway, but as a model for how to deal with situations like this it seems sound to me, as long as the operation can be trusted to either work or fail inexpensively and without side effects. You make the intended functionality the main program path; you handle failures as you see fit. However, I have to say, it appears to be less of a Haskell option than in most computer programming languages I'm familiar with. main = catchIOError (rename oldFile newFile) (\ e -> print (ioeGetErrorType e)) ... all I get out of that is "unsupported operation". I see no way to get to the POSIX error value, EXDEV, which isn't one of the few common errors that has a documented Haskell test. In OCaml for example, the well known errors are all enumerated (including EXDEV), but if you need to handle one that isn't, there's EUNKNOWNERR with a value. A casual look at the documentation suggests that while I can catch this error, Haskell doesn't give me the means to identify it. To make the most of my appearance here on haskell-cafe ... I find the notion of a "Zen" of this or that language kind of awkward. I suppose it's one of those usages that has taken on its own diluted popular meaning that has few traces of the original (goes back to "Zen in the Art of Archery"? I don't know.) But as little as the term may intend to refer the actual religious practice, that religious practice is a real thing with many adherents, a complicated doctrine with various schools, a lot of priests - and one where I find it very hard to recognize the appication to computer programming. Donn

Am Do., 15. Apr. 2021 um 10:24 Uhr schrieb Daniel Trstenjak < daniel.trstenjak@gmail.com>:

And it's the safest, because a move is an atomic operation [...]

... unless you are on Windows. ;-)

On Thu, Apr 15, 2021 at 11:05:25AM +0200, Sven Panne wrote:

Am Do., 15. Apr. 2021 um 10:24 Uhr schrieb Daniel Trstenjak :

And it's the safest, because a move is an atomic operation [...]

... unless you are on Windows. ;-)

I thought it is if you ensure that the move is done on the same device or partition. Greetings, Daniel

That would work but may not be the most efficient in all cases. On many systems, /tmp is a tmpfs, which being memory-backed is more efficient than a file on a physical disk or network, so writing to /tmp has performance advantages. On Thu, Apr 15, 2021 at 4:23 PM Daniel Trstenjak wrote:

Hi Josh,

the fastest and safest way is to create the temporary file in the directory of the final location and then move the file to its final name.

This way you ensure that the temporary file is always on the same device or partition as the final file and therefore a move is always possible.

And it's the safest, because a move is an atomic operation - which copy isn't - and therefore other processes will never see a partially updated file.

Greetings, Daniel