This is the mail archive of the
mailing list for the Cygwin project.
Re: A FAQ regarding defrag and permissions of nonadmin files?
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
>> 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