Delete File with Try, but still get errors

[CalvinFold]

BACKGROUND:
This is part of a larger script that scans user transfer folders and deletes items (files or folders) over a certain age. I don’t think AppleScript is trapping the dialogs the Finder presents when it hits a deletion error like “in use” or not having enough permissions or locked, etc.

I just want the file to be deleted, and if it can’t, then simply skip it and log it…and not require any dialog dismissing.

repeat with currently_deleting in files_to_delete
	tell application "Finder"
		try
			delete item currently_deleting
			delay 5
		on error
			my logMe("¢ DELETION FAILED: " & currently_deleting, 2)
		end try
	end tell
end repeat

[cwtnospam]

Is it in a Finder tell block? I don’t think you want item in there:

delete currently_deleting

[CalvinFold]

@cwtnospam

Is it in a Finder tell block?

The code again, maybe it didn’t come through for some folks:

repeat with currently_deleting in files_to_delete
	tell application "Finder"
		try
			delete item currently_deleting
			delay 5
		on error
			my logMe("¢ DELETION FAILED: " & currently_deleting, 2)
		end try
	end tell
end repeat

@cwtnospam

I don’t think you want item in there:

delete currently_deleting

I got the impression for server volumes to be explicit…use file, folder, or item. I’ve had horribly bad luck leaving out these specififers ever since I started playing in Leopard on server volumes. Maybe someone like StefanK can clarify?

[StefanK]

as cwtnospam wrote,
delete item currently_deleting
is bad coding. currently_deleting is the reference to an item.
And an item of a custom list is not the same as the element item of the Finder
The success of the script depends on the class of the items of the list files_to_delete

If the items are Finder file specifiers or aliases, this is sufficient

 tell application "Finder" to delete files_to_delete

I recommend this

repeat with currently_deleting in files_to_delete
	try
		do shell script "/bin/rm -rf " & quoted form of POSIX path of currently_deleting
	on error
		my logMe("¢ DELETION FAILED: " & currently_deleting, 2)
	end try
end repeat

If the paths are POSIX paths anyway, omit POSIX path of

[CalvinFold]

Well I had suspected as much…the shell version didn’t get all bent-out-of-shape about putting-up dialog boxes and nowI know how to do shell file deletetions to boot.

Once again, MacScripters to the rescue…thank you both!

By the way, is there a way to add sudo to that? Is it allowed? We get the occassional stubborn file that requires I use sudo to delete. Haven’t hit one with this script yet, but just in case.

---

So maybe some further education of a fellow scripter?

When do you use “file” and “folder” and “item” versus just the path reference itself?

For reference: the paths are being stored as text–“Unicode (UTF-16) text” according to Script Debugger. I’ve been staring at the little icons next to the references for a while, and never bothered to ask how the “alias” icon and the “UTF” icon should be treated differently. Until recently, for everything I did, it didn’t make really any difference. But as I try more complicated things, it seems to be making a difference.

As a follow-up…is there an advantage to using an alias versus a simple UTF-based reference, especially on a server?

[StefanK]

@CalvinFold

As a follow-up…is there an advantage to using an alias versus a simple UTF-based reference, especially on a server?

:lol:, how often will you ask this question yet?

I guess, you mix up a few things.

the terms file, folder, item (as element) belongs to the Finder (and System Events), you can use it only targeting the Finder or System Events.

Without using the Finder the basic file reference of the underlying UNIX system is a literal string path starting with a slash (also called POSIX path), which represents the startup volume.
The paths are slash delimited. All volumes are located in the invisible folder /Volumes. Using the shell you can refer to all files and folders on all volumes using these paths.

Unlike the shell AppleScript uses colon separated paths (also called HFS path), starting always with the name of the volume (never :Volumes or something like this).
In Finder or System Events the terms file, folder, item in front of a HFS path represent an object specifier.

There is also a file specifier in AppleScript itself, but pure AppleScript can’t delete, move, or duplicate files.
This file reference is used for example for the read/write command, Unfortunately there is a confusion with the file specifier of the Finder,
which is not the same thing.

You can use shell commands executed as root in AppleScript with the do shell script command and the parameter with administrator privileges,
which is exactly the same as sudo in Terminal. user name and password can also be specified.

[CalvinFold]

@StefanK

@CalvinFold

As a follow-up…is there an advantage to using an alias versus a simple UTF-based reference, especially on a server?

:lol:, how often will you ask this question yet?

Well, I’m getting the entirety of the answer piecemeal because I’m too naïve to know what further questions to ask each time. My apologies if it seems drawn-out on your end. I do feel a bit like I should know this stuff, but I don’t.

I’ve read plenty of AppleScript books over the years, but they never really spell this stuff out well and make a bunch of it interchangeable (“allowed” versus “correct” coding I suspect?). It’s not when you get down to it, as you’ve made clear, so I’m finding the assumptions I’ve built-up over 5+ years of doing this are failing when I try to do meatier work.

I am carefully reading and trying to digest this, so bear with me…

–I get the impression that if you even think you’ll be using shell, it’s safer to pass the UNIX path around a given script than rely on alias?

–What is the difference between “UNIX path” and “POSIX path”? When do you have to be concerned about “quoted form of”?

–For that matter what do you use alias for? Seems like every solution I get back these days from folks they don’t use it as much as days past?

–How do you know when you’re dealing with a file path, versus and alias, versus a “reference” to a file? Is one methodology better than another?
(This one always has always confused me, how the Finder can create a reference and you can keep dealing with it by reference, abstractly, even after you rename it, for example.)

–In the example here to delete files, I was using the Finder, so why was using “item” wrong if I was using a Finder command? Or am I further misunderstanding what you mean by “targeting the Finder”?

–I know you’ve told me, just days ago, that aliases/HFS paths are okay local, but not advised on remote servers (where UNIX paths are preferred)…assuming I understood you right, that is. But if one wants to be consistant, or not worry about whether a file is local or on a server, is there any issue using the UNIX path in both instances (local and remote)?

Dealing with files is a bit intimidating when you think about it…nobody wants to screw it up, especially at the shell level. I’ve gotten beyond read/write of a log file and now the larger world of manipulating files is giving me a headache.

Apologies again for the seeming redundancy…:rolleyes:

[StefanK]

@CalvinFold

I am carefully reading and trying to digest this, so bear with me…

–I get the impression that if you even think you’ll be using shell, it’s safer to pass the UNIX path around a given script than rely on alias?

on shared volumes, yes, on a local volume an alias is better

@CalvinFold

–What is the difference between “UNIX path” and “POSIX path”? When do you have to be concerned about “quoted form of”?

there is no difference. You need “quoted form” if a path contains space characters.
The shell (command line) takes space characters as parameter separators

@CalvinFold

–For that matter what do you use alias for? Seems like every solution I get back these days from folks they don’t use it as much as days past?

An alias is very versatile, it keeps its reference even the file/folder will be moved ore renamed.
A lot of AppleScript commands returns aliases like choose folder and choose file

@CalvinFold

–How do you know when you’re dealing with a file path, versus and alias, versus a “reference” to a file? Is one methodology better than another?
(This one always has always confused me, how the Finder can create a reference and you can keep dealing with it by reference, abstractly, even after you rename it, for example.)

There is no common way, it depends on the things around

@CalvinFold

–In the example here to delete files, I was using the Finder, so why was using “item” wrong if I was using a Finder command? Or am I further misunderstanding what you mean by “targeting the Finder”?

because you used item in a custom list, which is something completely different from a gathered Finder reference list.
Targeting the Finder means code within a tell application. block

@CalvinFold

–I know you’ve told me, just days ago, that aliases/HFS paths are okay local, but not advised on remote servers (where UNIX paths are preferred)…assuming I understood you right, that is. But if one wants to be consistant, or not worry about whether a file is local or on a server, is there any issue using the UNIX path in both instances (local and remote)?

you can use the shell also on a local volume. It’s just more comfortable to use the Finder. No POSIX path coercions, no taking care of things like "quoted form of "
Personally I’m using the shell always for copying/moving a large amount of files and for all find tasks (using Spotlight)

[CalvinFold]

@StefanK

@CalvinFold

–In the example here to delete files, I was using the Finder, so why was using “item” wrong if I was using a Finder command? Or am I further misunderstanding what you mean by “targeting the Finder”?

because you used item in a custom list, which is something completely different from a gathered Finder reference list.
Targeting the Finder means code within a tell application. block

So let me see if I understand this one (the rest were quite clear, thank you profusely!)…

Because the file path was literal text in a list (not an alias or reference), you don’t use “item/file/folder”?

But if I had acquired the list from, say, a drag-and-drop onto a droplet (which yields references if I understand correctly), then the item/file/folder would have been used.

(Okay, I know how much this sounds like AppleScript 101, but you’d be surprised what one can accomplish by never knowing these particulars…AppleScript used to be very, very forgiving I’m learning…)

[IanMcP]

I have a script that runs at night and zips folders left on a particular server share, and sends them to another site.

When I had finished the zipping and moving, I was using rm -f to delete the folders on the server, so they would not get processed again.

The process was causing all sorts of problems. (Most) of the contents of the folders would be deleted, leaving some files remaining, and I would get errors saying the files were in use. This would result in the folder becoming unusable and only possible to delete by the admin on the server the folders were on.

The vast majority of instances of this have been solved by using a “tell application “Finder” to delete (thisItem)”. The problems remaining are (I think) down to foreign characters in filenames corrupting the files.

The server share is Windows-based and I am connecting through AFP.

If there is a right/wrong way to delete files, what is it about rm -f that may be causing this problem?

Ian

[StefanK]

Hi Ian,

I guess, your problems are not shell command problems but access privileges problems.
And on windows shared volumes it’s strongly recommended to use only characters 0-9, A-Z and the underline character for file names
I even would avoid space characters

[IanMcP]

Stefan,

Interesting, I’ll look into what access is set up for me on that server.

The filenames are on files we receive from design agencies in Belgium and Germany, and when working on the macs, there is no problem - it’s when the jobs get archived off to an older Windows server. The filenames have to stay the same because of linking etc.

Thanks

Ian