Re: A FAQ regarding defrag and permissions of nonadmin files?

[Gmane User <fma at doe dot carleton dot ca>]

Brian Dessent wrote:
> Gmane User wrote:
>
>> I'm defragging the whole disk, so I need the defragger to be able
>> to access all files from whatever account it runs under.
>
> I've never had any problem doing that without having to specifically
> loosen any ACLs.

Let's make sure we're comparing the same situation.  I've used bash to
explicitly change permissions to go-rwx for most of my files.  This is
on a nonadmin account.  This is what chokes the defragger.  Do you
have the same circumstance?

>> About defragging as a service,
>> http://support.microsoft.com/kb/120929 says that the System account
>> has no more permissions than an admin account.
>
> I use O&O Defrag, it runs as a service as NT AUTHORITY\SYSTEM, and
> it defrags all my Cygwin files just fine without needing to set any
> special permissions.  It has been the same way with every other
> defrag program I've used too.
>
>> About defragging on boot-up, JkDefrag does this too, but still
>> needs an account to run under.  Is it possible for a defrag (or a
>> process) to run not under any account?  That is, does Ultra
>> Defragmenter actually do this?  Ultra Defragmenter would have been
>> my first choice, except that I ran into this caveat:
>
> At the point where UltraDefrag runs only the kernel and drivers have
> loaded, the Win32 subsystem and the SAM do not even exist yet --
> this is the whole point of doing it that early in the process, so
> that things like the registry hives are not yet open and locked.  So
> I think this runs in the absence of any user context.  And even when
> doing a normal defrag, UltraDefrag does the actual processing in
> kernel mode as a driver and at that level there are no access
> restrictions whatsoever.

Hmm.  That raises questions in my feeble mind.  I wonder why JkDefrag
requires the specification of a user account for the boot-up defrag.

Anyway, I will try Ultra Defragementer.  Thank you for the reassurance
and explanation below.  I have my fingers crossed.  Actually, I'll try
a boot-time defrag with JkDefrag first.  But Ultra is next, if the same
problems arise.

>>
http://groups.google.ca/group/alt.comp.freeware/browse_frm/thread/377f0ea5602cc584/855cc4e01f835029.
>> I described in my original post the barriers to ghosting in my
>> obsolete system, so I'm reticent to experiment with developmental
>> defraggers until they built up a bit of a track record.  This
>> decision has more to do with safety than how well the algorithm may
>> be coded up.
>
> Keep in mind that all of these things are using the same code for
> the heavy lifting of actual defragmentation.  That is implemented in
> the NTFS.SYS filesystem kernel driver; none of the tools actually
> touch the raw disk, they just send an IOCTL to the filesystem
> telling it to move a file extent from A to B.  The only thing that
> differs is the high level algorithm that decides what goes where,
> but none of them do the actual moving.  The risk of data loss
> therefore is more or less constant and does not depend on which tool
> is being used, as I see it.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/