Prev: VB6.0 SP4 can't be instlled - 'cannot find the Visual Studio common directory'
Next: ActiveX EXE Books etc?
From: Bob Butler on 26 Oct 2009 17:58

"Karl E. Peterson" <karl(a)exmvps.org> wrote in message
news:ueoZONoVKHA.504(a)TK2MSFTNGP06.phx.gbl...
<cut>
> I can one-up that! <eg> Right-click on Recycle Bin, select Properties,
> check off "Do not move files to the Recycle Bin. Remove files immediately
> when deleted."

Probably one of the first things I do when setting up a new system (for
myself anyway). Right after setting Windows Classic style and the "classic"
start menu and telling explore to stop hiding files and extensions.


From: Tony Spratt on 27 Oct 2009 04:56
"Bob Butler" <noway(a)nospam.ever> wrote in message
news:eziBteoVKHA.2340(a)TK2MSFTNGP04.phx.gbl...
>
> "Karl E. Peterson" <karl(a)exmvps.org> wrote in message
> news:ueoZONoVKHA.504(a)TK2MSFTNGP06.phx.gbl...
> <cut>
>> I can one-up that! <eg> Right-click on Recycle Bin, select Properties,
>> check off "Do not move files to the Recycle Bin. Remove files immediately
>> when deleted."
>
> Probably one of the first things I do when setting up a new system (for
> myself anyway). Right after setting Windows Classic style and the
> "classic" start menu and telling explore to stop hiding files and
> extensions.

How annoying are those default settings? Yes, I *do* want to see extensions,
no I *don't* want you to hide files from me and, believe it or not, I *do*
need to see inside the Windows folder.

As an aside, some of my users have extensions hidden for common file types
and also have a fairly straightforward approach to renaming documents,
leading to them thinking they have called a Word document, for example,
"Audit Report." (note the full stop). This means the file ends up actually
being called "Audit Report..doc" (two dots). Fine and dandy - until you try
to upload it to SharePoint. The error message, of course, doesn't actually
identify the problem - cue trial and error until you switch extensions back
on and see what should have been obvious.


From: amdrit on 30 Oct 2009 16:22
Isn't moving a file more operations and thus a longer process then simply
deleting the file you found that matches the criteria?

This sounds like something that you are doing on a regular basis, I wonder
if you have a lot of fragmentation on that drive. That could another reason
for slow processing.

Even still, if you are going to itterate over a large directory of files
only to move them and then ultimately delete them based on date, I'd perform
the delete right there, or queue it up for another thread to delete from.


"Saga" <antiSpam(a)nowhere.com> wrote in message
news:OkrkjdkVKHA.1792(a)TK2MSFTNGP04.phx.gbl...
> Thank you all for your ideas. I was out from Fri to Sun eve at iHobbyExpo
> and only now am I getting settled back in.
>
> Thanks for the links to routines, examples and more information. I will
> have
> a look at them. Both Bob and Dee have a good idea in that perhaps it isn't
> so much making the delete process faster, instead a differrent approach is
> necessary. Grouping the files into folders and then only checking and
> deleting
> the folders would definitely be a better to do do this process.
>
> OpenVMS sounds interesting, but not the solution for this particular case
> because it involves a new (and different) piece o software, thus having to
> go
> through a Dilbertian approval process. :-S Thanks for this idea though. I
> will look into this.
>
> The delete process runs various times a day. Obviously, it is the first
> time that
> it is run that takes an extremely long time. However; running it during
> non
> business hours is a good idea and I am able to schedule it within the main
> app.
>
> Karl, the botteneck occurrs at each step. Getting the file names, checking
> for its date and then deleting it. I am moving away from using Dir() and
> more the Windows API calls. After looking at the code and performing
> some tests on Thursday I came to the conclusion that the process needed
> a major overhaul.
>
> Nothing against using the file object, but I suspect that the security
> people
> would want my head if I attempted to use it. As much as it could be a good
> solution, I'll have to look elsewhere.
>
> Again, thanks for all your ideas. Saga
>
>


From: Ralph on 30 Oct 2009 18:33

"amdrit" <amdrit(a)hotmail.com> wrote in message
news:urg6P7ZWKHA.3696(a)TK2MSFTNGP02.phx.gbl...
> Isn't moving a file more operations and thus a longer process then simply
> deleting the file you found that matches the criteria?
>
> This sounds like something that you are doing on a regular basis, I wonder
> if you have a lot of fragmentation on that drive. That could another
reason
> for slow processing.
>
> Even still, if you are going to itterate over a large directory of files
> only to move them and then ultimately delete them based on date, I'd
perform
> the delete right there, or queue it up for another thread to delete from.
>

Within the same medium a "move" is usually just a renaming, ie, no bits get
moved around. A delete means finding each of the 'storage blocks' and
marking them as invalid, ie. a process than takes more clicks.

Moving files to a single folder is merely a quick way to "queue them up".

Severe fragmentation could have a possible impact on performance and is a
point no one brought up.

-ralph


First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: VB6.0 SP4 can't be instlled - 'cannot find the Visual Studio common directory'
Next: ActiveX EXE Books etc?